really depends on use case. Our spreadsheets (finance, derivatives) can get damn big, but there are 3 reasons they persist: ease of modification, speed of the interface, and easy integration with powerful analytics libraries we use.
Now I have functioned in a python based environment before, and that had some huge benefits (especially when working on tick level data, or data that was just a pain to manage in VBA until I got output down to a reasonably visualizable size) , and I regularly push for trade level data and details to be put off into a SQL database as it is pretty easy to write flexible queries to get what I want out. But visualizing data, interacting with historic data (user forms for display), generally integrating with many other financial libraries (bloomberg and reuters for realtime, internal quant libraries for complex calculations), and having a fast interface out of the box is amazing.
I've been at places that have tried to replace excel as the interaction layer. The problem is, for all its problems, most coders cannot hack together, on their own, a better GUI that is as performant or easily interacted with. Sometimes it isn't the data analysis layer (which if at all possible, we like to farm off somewhere else for perofrmance), but everything else that makes the spreadsheet far superior. And of course, I can modify and adapt someone else's work far faster than anyone using code. On a regular basis I can build up a complete tool in excel 10-20x faster than any coder can write me something outside of it. And most of the time a 95% correct answer in 1 hour is far more useful than a 100% correct answer in 3 days.
Now saying that, once the office ribbon started, that was the beginning of the end. Slowly the interface is getting too clunky to waste my time with when it was the simplest things I required. Now I try to do a lot of my work in a proper coding language and write out files I can parse quickly in vba and display in excel.