I've written a book on this (hit upload five minutes ago! release Monday!) which hammers on this point (and all the stuff surrounding this issue). I think Solidity is actually designed with worse is better in mind, because Ethereum is the first smart contract platform that anyone actually used. Some tried doing them in Bitcoin, but Ethereum's the first that gets lots of action. And so many other blockchains lift the smart contract functionality straight from Ethereum.
As far as I can remember, the EVM has never failed, just programmers.
The register globals issue could have been avoided at very little cost, if any cost at all, to the popularity and spread of the language and many millions of dollars and much personal information would have been saved.
I spent about three thousand words on the smart contracts chapter, attempting to conclusively stab this bad idea in the face and supply a suitable rhetorical ammo dump for anyone faced with having to deal with these things to kill the idea stone dead. Absolutely everything about smart contracts is terrible and misconceived. I don't believe there is any way to do them right, because the idea is fundamentally wrong.
Here's (an older draft, need to update) what I actually say about Solidity and Ethereum smart contracts: https://davidgerard.co.uk/blockchain/ethereum-smart-contract...
So if you're talking about Ethereum as a bad implementation of a good idea, you're weighing up reality against something that was a hypothetical from 1994 to 2014.
In any case, there's plenty really obviously wrong with the idea of immutable smart contracts. Legal code is a bad match for computer code; immutability means changes in circumstances can't be allowed for; immutability means you must code with zero bugs; the oracle problem (getting real-world data in and out of your smart contract) ...
"Dr. Strangelove" is the story of a smart contract going wrong, unstoppably, immune to human intervention.
Szabo's stuff is better than the reality - he does actually understand law as well as code, and at least early on he considered there was a role for human intervention - but it's still the sort of thing that's "interesting" rather than "a good idea".
They did put themselves way out there, and that takes ambition, but also hubris. I wish they were able to figure out which one was driving them at certain points a bit better, as while some of these problems are because they are doing new and interesting things, some are old as dirt for computing, and there's little defense.
If some company tried to tout a new language with all the pitfalls of C, but none of the benefits of being really inter-operable and known the same way, I'd like to think we could recognize that as having some very bad design choices given what we've learned from C, and at little benefit other than being different. Ignoring decades of research and experience on the topic through ignorance is not laudable, even if you've put yourself out there. I can't help but feel we have a similar scenario going on here.