“Because it’s better than Java and PHP”
…damming with faint praise…
I think there’s some confusion here - you gave up on a language to go back to an application? Those are two different categories, of course the one won’t do what the other does near as as well. Nor should it - “being a spreadsheet” is not Python’s forte. Or by Excel do you mean Excel+VB?
There are Python frameworks like Django that allow rapid creation of high quality web services. Nothing to do with the language. It is just that Python lends itself to a lot of useful things. In the Scientific arena Python competes head to head with Matlab via numpy and scipy. Again, nothing to do with the language.
Persistent storage is an interesting one. It is a significantly more complex problem than just being able to write data to a file. Excel is about as close to the bottom of the pile as it gets. Data interchange via csv files isn’t exactly high end either. There was a whole area of research into persistent storage and language design. Languages like PS-Algol and Napier-88. It isn’t a simple problem. Type systems are complicated, and a real persistent storage abstraction needs to tie in. Sadly all we have in most areas is serialisation of objects. This is way short of what is possible.
Other than that, a lot of system just front end an SQL database, and use that for persistent storage. That isn’t language level in any meaningful sense either.
Is it too obvious to suggest spam?
And here we have an example of downplaying the importance of the user interface and persistent storage in language design.
Yes, if you define “language” as divorced from interface and storage, then interface and storage are not part of language. If you define “language” as being only spoken, then what I am writing here is not “language”. If you define “language” as being non-visual, then sign-language is not language. If you think architects and designers are pretentious, then you probably don’t accept the idea of communicating using a visual design language.
You may remember that there was a significant debate about what should be included in “computer languages”. c was a language of only 32 key words that did not include any I/O at all – all that was left to the operating system to provide. Pascal, at almost the same time, was a language that included “Writeln” as part of the language definition.
You can choose to use a narrow definition of language, that doesn’t include the user and system I/O. My point is that doing so is not historically accurate, it’s intellectually limiting, and it’s a misleading way to approach language productivity.
Language in any computer sense has defined syntax, semantics, and a type system. If we take your definition of a language, the entirety of Windows is a language.
Excel is implemented in a language just as a book, a movie, ballet, music, or stage play is written in a spoken or visual language. Excel embodies a couple of languages internally, the simple expressions in cells, and VB. Visual languages exist, but have never made much progress. Simple things like DX-Explorer have a visual language. Excel doesn’t have a visual language. It has an ad hoc visual display motif. Spreadsheets themselves are a paradigm. Just like a relational database is.
Whether a language should have persistent storage or a user interface as part of its definition is an open question. Personally I would like to see persistent storage, but the problem here is that you cease to have the ability to usefully interact with other tools when you do. User interface is just too big a problem. Excel has a very primitive GUI capability. Much of its better capabilities are not part of any language, but simply bolt-on libraries. Compared to something like Mathematica it is stone age.
In many software designs the axiom is - do one thing and do it well. Excel is a very good spreadsheet. It is a dire GUI, appalling coding environment, and utterly unsuited to anything more than the most primitive of data storage applications. One of the problems I see in many of the “softer” sciences is a habit of doing everything in a spreadsheet. It ends in tears. There is no useful capability for proper software engineering. No useful version control, no test frameworks, it is impossible to collaboratively write spreadsheets. It has a type system about as primitive as C. Most people don’t even attempt to comment or document what they have created. Maintenance is close to impossible by anyone other than the author. And so it goes. In the sense of being a language for software engineering, Excel is a non-starter. As a tool for science it is desperately flawed.
There have been very interesting integrated systems. Probably the most well known is Smalltalk. But there have been others. Mesa/Cedar, also from Xerox PARC, the various Lisp Machines, and some of the persistent environments. But technology has kept moving too fast, and the potential that exists (for instance in ubiquitous network connectivity and high powered self contained portable devices) makes it hard to design a fully integrated environment that isn’t obsolete before even a prototype is written.
Only if you have infinite storage (tape).
Excel is limited to 16384 rows. Pedantically no extant computer as really Turing complete. But close enough for folk music.
Then again, a Turing Machine is Turing complete. Not the best programming environment, but there it is.
I mean, this is fine until you’re working with terabytes or petabytes of data, or even gigabytes over maybe 2. I agree that Excel has some serious benefits if you just need some processing and organization over small sets of test data, I used it for undergrad physics labs despite knowing numpy pretty well by that point. But it becomes progressively more unwieldy as your need for analysis becomes more complex or the size of your data becomes larger.
(And to be fair, even numpy+pandas isn’t exactly a shining star of performance when dealing with big globs of data or complicated processing schemes, but it’s at least reasonably functional and often can be optimized via Cython or whatever else to be performant enough; unlike Excel which just utterly degenerates in that case)
I’m happy with a broad definition of language - I’m still not seeing one where “Excel” is a language, though.
Pedantically, of course, standard C is not Turing complete. Behaviour is undefined unless you have infinite stack space.
And the relation to Python is that common-or-gardern variety Pythons use the C stack and aren’t Turing complete either 
…Although I’ve never needed to use NumPy, I have done optimisation problems in extended Excel – using Excel extensions written in C. I wouldn’t rate “ability to interface with code written in another language” as a reason to choose between any of the coding languages I use. But in answer to the OP:
One of the early, original use-cases for Python was for scripting mathematical calculations written in another language, on a platform that did not support Excel, before Open Office was any good at all.
Excel itself offers a highly productive GUI and a highly productive coding environment. It is difficult to give a generous interpretation to comments to the contrary.
Excel is/was a natural choice for processing 2D (and, at a pinch 3D, (and if required, nD))) Arrays of Numbers, which have a clear natural representation and what was, 20 years ago, a very clear, natural way of dealing with arrays as objects, and arrays one element at a time.
Compared to VBA/Excel, Python specifically benefits from language support for Functional Programming, which, amongst other things, offers a much improved, superior, clear, natural way of dealing with arrays of data.
Coupling the two – the spreadsheet and functional programming – would seem a natural winner, and at least one version of OO Calc now has support for Python. It’s not suitable for what I’m doing, but particularly given the poor support for VBA in OO, I wouldn’t be surprised if some of the financial calculations migrated to Python over the next couple of years.
Just chiming in to add a +1 for Rust! 
I’ve been a sufferer of C++ Stockholm Syndrome for a decade and a half, and Rust is the language that has charmed me into ditching C++ and never looking back.
Incidentally, it has also kind of been the last nail in Python’s coffin for me. For several years I was basically a full-time Python developer, and while it was always a language I kind of liked, those years of experience led me to an inescapable conclusion: Python (and more generally any dynamically typed language) is not suitable for large projects. Once you get past ten KLOCs or so, the complexity incurred just becomes too great; static analysis is all but impossible, and debugging is an unlocalizable nightmare.
I still used Python for small tasks though – small applications, glue code, shell scripts, that sort of thing. But once I started learning Rust, I realized that it gave me the only benefits of Python that I cared about – abstraction, expressiveness, and terseness – with none of the drawbacks of not having a type system. So now I’m happily Python-free as well.
(I still have to use C at work though. :p)
I’ve actually been thinking of starting a Rust thread. It’s become my main development language. It has some problems (trait bound-splosion, for instance), but for the most part it marries just the right amount of explicitness with the right amount of boilerplate.