You assume that the only reason that Mozilla is the only major player to push JavaScript as the way forward is that Brendan invented JS. Another interpretation which is less cynical toward Mozilla is that the other players are most interested in their own platforms, whereas Mozilla is most interested in the Web as a whole. A JavaScript runtime is the one runtime that all browsers have, so rather than fragment the landscape with a second runtime, Mozilla is pushing JS as the way forward.
You assume, as if it were an axiom, that compiling other language to JavaScript is less efficient than compiling to LLVM bitcode and/or x86/ARM native code. I'll take these separately.
Targeting JavaScript versus LLVM bitcode: For good performance, either of these will be JIT-compiled to native code. To claim that LLVM bitcode is a better target, you need to show that some JIT compilation technique implemented by LLVM/PNaCl is made impossible by JavaScript the language. JS typed arrays provide a C-friendly memory model; I don't know of anything else that's missing. I'd be happy to be educated though.
Targeting JavaScript versus native code: Last I checked, Google is not going to push NaCl for standard web apps until PNaCl is ready. So we'll need the cross-platform target and JIT compilation anyway. You may argue that even when PNaCl is ready, application developers will also ship x86 and/or ARM builds for maximal efficiency. But let's dig a little deeper: in all likelihood, the PNaCl, x86, and ARM builds are all generated by a compiler from a single intermediate representation. In principle, why couldn't a subset of JavaScript be compiled to equally efficient native code? Even assuming that offline ahead-of-time compilation yields more efficient code than JIT compilation, a browser could observe which apps the user uses most, and apply more aggressive offline compilation to those apps. So it is by no means imperative that application developers ship native code.
You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper, is unequivocally holding back the Web as an application platform. Let's drill down into specifics. What features do NaCl and Pepper provide that aren't (yet) covered by standardized APIs? My understanding was that Canvas and WebGL are helping a lot.
Finally, you may be unaware of some limitations in NaCl. Specifically, because of the way NaCl validates code, you can't run a JIT compiler on top of NaCl. So, if you thought that NaCl would be a better target for Java/Python/Ruby/pick your favorite than JS, think again. For good performance, you'd need something to compile your source language to something else anyway, either JS or LLVM bitcode. Might as well be JS.
I think I have demonstrated that Mozilla's insistence on JS and other standards is not holding back the Web as an application platform by any means. Indeed, none of the other major players you've mentioned, not even Google, is as serious about the Web -- the open Web -- as Mozilla.