Except you can do it if you know what you're doing.
No one is saying to manage millions of records etc.
But you can get more mileage out of excel than people think - and people who half understand it are the worse because they know enough to know that it doesn't work.
Custom solutions are great - but aren't always the answer and with proper process Excel will work just fine in many use cases.
How can you achieve anything equivalent to unit testing? How can you do any kind of change control (unless you treat every edit to the sheet as a change)? Excel does some things well but for anything that needs to work robustly as part of a process (as opposed to one-time exploratory data analysis) it lacks things that were basic in 1996. It's an "unsafe at any speed" situation: it may work as long as you do everything right, but it's missing basic safeguards as soon as you make a single mistake; I'd put it in the same category as using a memory-unsafe language.
>Except you can do it if you know what you're doing.
Ye gads, why didn't we think of that in any other programming language? If we know what we're doing we can do whatever we feel like, and if we get the wrong answers, it was obvious that we didn't know what we were doing which can be fixed by just knowing what we were doing!
Excel's only use case is for data that fits on one screen, or an exploratory poke at the data to see what's in which column and if there are any patterns you can eyeball. Then you put those hunches in a script and start doing the work for real.
No one is saying to manage millions of records etc.
But you can get more mileage out of excel than people think - and people who half understand it are the worse because they know enough to know that it doesn't work.
Custom solutions are great - but aren't always the answer and with proper process Excel will work just fine in many use cases.