Let's assume, for a moment, that your position is basically right - that we need to come up with a language-independent VM, and that JavaScript isn't going to cut it. We'll even imagine that we have the ideal spec sitting in front of us, which does everything that anyone will ever need (which isn't going to happen).
How can we possibly get there from where we are now? Basically, we can't, for various reasons.
Anything that doesn't work on existing deployed web browsers is dead on arrival. If the VM won't work on the vast majority of deployed browsers, then I can't use it. It would take years for JavaScript-only browsers to die off enough that I can use the VM, especially Internet Explorer and various phone / tablet browsers (Android being an obvious problem, since most manufacturers do not release updates, or release them years late).
So, if I wanted to use the VM before 2020, I'd have to have a JavaScript-only fallback. I just don't have any other option, because I certainly can't use PNaCl (Chrome-only) or Flash (effectively desktop OS only). If I have a fully functional JavaScript-only solution, which works right now, in all existing browsers, what do I need the VM for?
That's assuming that we could possibly get any agreement on a VM. That's never going to happen, for a number of reasons.
The only browser manufacturer actually interested in a VM is Google. Hence, they're working on PNaCl. Microsoft, Apple and Mozilla are all against the idea for various reasons, ranging from pragmatic to idealistic.
There are far, far too many different ways to do a VM, which depends largely on what languages you want it to run. A VM designed for C / C++ code (which asm.js pretty much is, as is LLVM) is very different from something like the JVM or .NET CLR, which is different from the kind of VM a JavaScript implementation has. Different groups of people want completely different things, which are often diametrically opposed to one another. The kind of VM a game developer would want is completely different than the kind of VM you'd want for developing business applications, and either VM would be essentially useless for the other group.
Besides that, what's the point? Modern JavaScript JITs are stupidly fast, even when they have virtually no information about the code they're running (types, in particular). You can already cross-compile a number of languages to JavaScript, which often treat it as a low-level target.
Remember, the web is a huge collection of different systems (browsers, servers, websites, development tools, and so on) which really can't just be upgraded in one pop. It has to evolve, and it has to work at every step of the way. If something doesn't work, or isn't usable, it tends to die, even if it was a really good idea.
There's one possibility, though:
People start using JavaScript as a compilation target. Improvements in JavaScript engines make this approach viable, and reasonably fast. Compilers tend towards using JavaScript in a certain way, which is kind of predictable. Browser manufacturers notice this, examine the subset, and come up with a spec describing it, and a plan for optimizing it. Compilers start producing the standardized subset, and JavaScript VMs gradually start adding optimizations for the subset. Browser vendors start competing with one another for performance, pushing the optimized VM close to native speeds.
Then, eventually, someone might take what those browsers are already doing, write a bytecode implementation of it, and a JavaScript shim that turns the bytecode back into JavaScript to support existing browsers. If there's any advantage to it at all, this bytecode would be trivial to adopt in a browser (it's close to what they're already doing), so there's no reason for browser manufacturers to resist it. If there are no advantages to it, nobody will bother.
It'll probably end up being a perfectly reasonable feature, based on a design that would be completely insane if you designed it from scratch, but works anyway.
Let's assume, for a moment, that your position is basically right - that we need to come up with a language-independent VM, and that JavaScript isn't going to cut it. We'll even imagine that we have the ideal spec sitting in front of us, which does everything that anyone will ever need (which isn't going to happen).
How can we possibly get there from where we are now? Basically, we can't, for various reasons.
Anything that doesn't work on existing deployed web browsers is dead on arrival. If the VM won't work on the vast majority of deployed browsers, then I can't use it. It would take years for JavaScript-only browsers to die off enough that I can use the VM, especially Internet Explorer and various phone / tablet browsers (Android being an obvious problem, since most manufacturers do not release updates, or release them years late).
So, if I wanted to use the VM before 2020, I'd have to have a JavaScript-only fallback. I just don't have any other option, because I certainly can't use PNaCl (Chrome-only) or Flash (effectively desktop OS only). If I have a fully functional JavaScript-only solution, which works right now, in all existing browsers, what do I need the VM for?
That's assuming that we could possibly get any agreement on a VM. That's never going to happen, for a number of reasons.
The only browser manufacturer actually interested in a VM is Google. Hence, they're working on PNaCl. Microsoft, Apple and Mozilla are all against the idea for various reasons, ranging from pragmatic to idealistic.
There are far, far too many different ways to do a VM, which depends largely on what languages you want it to run. A VM designed for C / C++ code (which asm.js pretty much is, as is LLVM) is very different from something like the JVM or .NET CLR, which is different from the kind of VM a JavaScript implementation has. Different groups of people want completely different things, which are often diametrically opposed to one another. The kind of VM a game developer would want is completely different than the kind of VM you'd want for developing business applications, and either VM would be essentially useless for the other group.
Besides that, what's the point? Modern JavaScript JITs are stupidly fast, even when they have virtually no information about the code they're running (types, in particular). You can already cross-compile a number of languages to JavaScript, which often treat it as a low-level target.
Remember, the web is a huge collection of different systems (browsers, servers, websites, development tools, and so on) which really can't just be upgraded in one pop. It has to evolve, and it has to work at every step of the way. If something doesn't work, or isn't usable, it tends to die, even if it was a really good idea.
There's one possibility, though:
People start using JavaScript as a compilation target. Improvements in JavaScript engines make this approach viable, and reasonably fast. Compilers tend towards using JavaScript in a certain way, which is kind of predictable. Browser manufacturers notice this, examine the subset, and come up with a spec describing it, and a plan for optimizing it. Compilers start producing the standardized subset, and JavaScript VMs gradually start adding optimizations for the subset. Browser vendors start competing with one another for performance, pushing the optimized VM close to native speeds.
Then, eventually, someone might take what those browsers are already doing, write a bytecode implementation of it, and a JavaScript shim that turns the bytecode back into JavaScript to support existing browsers. If there's any advantage to it at all, this bytecode would be trivial to adopt in a browser (it's close to what they're already doing), so there's no reason for browser manufacturers to resist it. If there are no advantages to it, nobody will bother.
It'll probably end up being a perfectly reasonable feature, based on a design that would be completely insane if you designed it from scratch, but works anyway.