Perhaps for your OpenGL games, but for some business application originally written for VB4 that basically draws a bunch of forms and puts stuff in a database, that's more than fast enough for some compiler that took VB4 and turned it into JS.
This is basically the reason d'etre for NaCl as far as I can tell: it was at various points advertised as for games and other 'high performance' stuff, but the more probable commercial reason for it is to leverage companies on to a non-Microsoft platform through an easy migration path. So I think the hypothetical VB4 compiler comparison (or a million similar "business app migration" examples) is pretty fair.
[edit: per subsequent comment, the notion that GC somehow can't be implemented is nonsensical]
I think the difficulty of implementing GC would be the lack of access to stack primitives, something that would be impossible to provide in a way that was backward compatible.
By that I mean the ability to inspect the stack and determine the values present there and determine whether or not they point to 'heap' allocated memory.
Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR?
A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages.
I took that to be actually talking about the other way around -- accessing JS GC'd objects from the asm.js code's heap and having it work correctly (which is currently onerous). I don't think that helps implement GC of the asm.js heap.
Problem is, it's way too large and way too slow. People aren't doing these things because they simply aren't feasible.
If you could compile Python directly into that asm.js subset of JavaScript, things would be okay. However, emulating a whole CPU and running some Python interpreter on top of that won't be okay. Even if you would magically reach 100% of the regular speed, it just would be way too fat.
This is basically the reason d'etre for NaCl as far as I can tell: it was at various points advertised as for games and other 'high performance' stuff, but the more probable commercial reason for it is to leverage companies on to a non-Microsoft platform through an easy migration path. So I think the hypothetical VB4 compiler comparison (or a million similar "business app migration" examples) is pretty fair.
[edit: per subsequent comment, the notion that GC somehow can't be implemented is nonsensical]