I really liked this comment (by khoth): "And once we have standardised bytecode, the next logical step would presumably be to improve performance by creating CPUs that can execute it directly. In 20 years we'll all be back where we started."
There's a whole hell of a lot of optimization that gets done in the JIT layer besides just translating bytecode to machine code, and you want all that stuff to get done in software rather than trying to build it into your processor. Once you've done all that stuff, emitting actual assembly code isn't really the hard part, so you might as well just design a processor that you can make fast, give it a simple general-purpose instruction set, target that instruction set in your JIT, and then add a few special goodies as you need them for things that are really, really hard to do fast without specialized hardware support.
Only if people forget the past. If the past is any indication, people will forget. What were we talking about again?
After investing lots of time and money into creating a JM, the companies were chagrined to find a general purpose processor with a good JVM (especially with JIT) could run circles around a direct-execution processor.
I'll propose an alternative, fix JavaScript by adding APIs like ByteArrays and shorts and a proper int to the language. Over time, JS could become an excellent IL. We can standardize on intermediate bytecode, but like all things in web adoption, it will probably be the path of least resistance that works. (Who would ever give HTML graphic, multimedia, and threading abilities?)
They've been slowly withering away for the past couple of years (at least judging by the number of cars in their parking lot - I work in the building they are in). They just announced a cloud-based product based on their systems, so maybe there's still some life there.