The "and" and "the" line was from Mary McCarthy in reply to Lillian Hellman. You're Hellman :-|.
You wrote:
"As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation."
The empty rhetorical flourish ("I only have to point out...") aside, this is rank question-begging. You assume that JS as Dart target being too slow must mean DartVM should win because of "competitive" force. Wrong on at least two counts (I'll ignore market power abuse):
First, DartVM may be faster at semantics JS supports due to optimization problems on the JS engine side. V8 in particular lost its founding team to DartVM, except for some moonlighting. Therefore "competitive" does not mean that JS cannot improve to be as fast when compiled from Dart as when the Dart source runs in DartVM.
Second, DartVM may have types and optimizations that JS lacks, bignums for example. Again "competitive" does not mean JS cannot change, and in fact bignums have been on the ECMAScript Harmony agenda since 2010, before "Dash" leaked.
In any competitive market with deep tech, there are lots of ways to meet a set of developer-facing language support/performance requirements. Even with all Google's billions, Dart and Chrome decision-makers couldn't ignore the compile-to-JS alternative and continue to justify developing and shipping DartVM + OilPan + all else not fully in hand to support JS and Dart with no performance regressions. Compiling to JS is the sole path forward for Dart on the Web precisely due to competition.
Citing my argument about bignums is perversely wrong, unless you assume DartVM is the only solution to any DartVM vs. dart2js performance disparity.
Such an assumption, like the one you seem to have made about NaCl, is anti-competitive, uneconomic, magical thinking. It requires indefinite amounts of time and money to fund all the work to have two VMs, a super-GC to collect cycles, write barriers as part of that super-GC, and more optimization to overcome the performance regressions imposed by those barriers (if possible). It assumes JS can't more cheaply be extended to be a fast-enough target language. You offer no proof.
BTW, you started out with NaCl and I still think you're mistaken about something pretty fundamental. NaCl was never proposed as a Web standard. Ok, suppose you mean PNaCl. The problem remains that PNaCl required a big API, Pepper, to reach the guts of chromium/Blink (originally WebKit) and the underlying OS. The problem with PNaCl was always Pepper, and again: competition killed Pepper as a cross-browser API.
It takes longer (it would have happened sooner with more cooperation from Google earlier, instead of the malinvestment on these two big follies), but JS is getting SIMD and shared memory threads, which are among the last few bricks still standing in the Pepper wall.
So PNaCl is evolving with Emscripten/asm.js now -- precisely due to competition -- and I would not hold my breath for PNaCl to remain based only on LLVM bitcode (with fixes requiring years and millions, to remove unspecified behavior). But feel free to hold your breath and then blame the "vendor cartel" if you like.
On that "vendor cartel" point, there are more web engines coming along, Servo (an open source project with multiple paying companies involved) among them. There's no cartel, just a big compatibility hill for any new engine to climb.
Adding gewgaws like NaCl and Dash slows down that climb. It's uncompetitive for the would-be market entrant. Why you think this requires collusion ("cartel") or Satanic pride ("reign in Hell") is unclear. Do you get many billion-dollar free lunches where you live?