Python (like Lua, Perl, etc.) had to evolve backward-incompatibly, and thankfully could do so as a Unix-y and server-side command line. As a browser-embedded scripting engine, don't-break-the-web selection pressure would have forked and stunted early Python or any other language about as badly as JS, ignoring the spurious (to what I wrote) "Blub was a better language to start from" benefit. That's the main point.
Python was never an option, anyway, as I've remarked in many places. Netscape management insisted on "make it look like Java", and time pressure combined with "don't be too big a sidekick" angst from Sun kept such things as classes out of JS in the early days (it took till ES6 to add classes). Python had OS-specific APIs and an unsafe FFI to boot, so would have been forked by stripping out many features, too. Fuzz testing would have exacted further costs, but I'll stop here. Python was never an option in the '90s, for many reasons.
BTW, I did help manage and fund Mark Hammond (then at Active State), when I was leading Mozilla in the early noughties, to add C-Python as an alternative scripting language engine to Gecko. That code was for Active State's Komodo IDE, which used Python in XUL script elements. But the DOM complexity tax was bad enough that Gecko maintainers ripped it all out just a couple of years ago. See
https://bugzilla.mozilla.org/buglist.cgi?order=Importance&re...
So I know a lot more about what you're blithely talking about, from actual experience, than you do.
Finally, your hyperbolic language ("tragedy") is off target. Mozilla is way underfunded compared to all of the other browser vendors. It could and still can least afford to jam in other languages, plus pay the requisite inter-heap cycle collector and write-barrier overhead costs you neglect to mention. Falling on this sword would have done nothing -- did nothing even with Mark Hammond's fine work -- to displace JS or get other browsers on board. It would have helped Mozilla fail, though.
You'd do better to cry that Google did not fund, out of its massive profit margins and market cap, engineers to add such things to other open source engines -- as Microsoft has done with Pointer Events for Gecko and WebKit.
Please do name a standard that Mozilla supports which is both (a) more complex than multiple language runtimes embedded and integrated with a low-overhead-enough inter-heap cycle collector; and (b) not already obligatory for competitive browsers to support (as Dart certainly is not!). Take your time; list your references.
Apple and Microsoft won't fund such follies, and even Google has yet to ship Dart on top of Oilpan in Chrome (https://www.chromestatus.com/features/6682831673622528).
This is not a case of me as past Mozilla leader ducking "responsibility" to fund your pet follies based on breathtakingly incomplete HN-comment assertions about low complexity from you. I don't owe you or anyone that big a free lunch. (How about you write the patch and submit it, with tests, and then talk to Mozilla or any other open source browser project.)
Rather, it's a set of three confirming signals showing that while talk is cheap, multiple independent language engines in one browser certainly are not. Only Google has the funds and engineers to burn on such speculative work. And it's an open question whether Chrome has the market power to make any such extension "stick" as a de-facto standard.