One key benefit to asm.js is that it turns of garbage collection. Given that GC pauses are still a major nuisance (seriously, try simply flashing a div or canvas in a requestAnimationFrame loop, and you'll see it even in recent versions of Chrome), that is potentially a major win for game development.
Of course, the real solution is to fix the garbage collector, or (maybe) better yet, give user code a way to switch GC algorithms based on app-specific needs. Until then, the ability to manually manage memory is nothing to sneeze at.
asm.js does not turn off garbage collection. Instead, programs written in this style do not allocate many objects, so the garbage collector does not need to run much. asm.js programs allocate a single giant block of memory, and then do their own psuedo-manual-memory-management within that block.
>Q. Why not just keep optimizing JavaScript JIT compilers instead?
>A. No need to stop! But JIT compilers have less predictable performance based on complicated heuristics. The asm.js model provides a model closer to C/C++ by eliminating dynamic type guards, boxed values, and garbage collection.
He's saying it eliminates garbage collection by emitting code that doesn't dynamically allocate any objects. The GC is still active it just never needs to do anything. If you remove the 'use asm' pragma the code will still not allocate any objects and hence the GC will still never need to do anything.
Ah, I see what you're saying. The point being that you still have the GC for any non-asm.js code on the same page. And I suppose by the same token, you could "opt out" of GC without asm.js by using various techniques to eliminate allocations.
Of course, the real solution is to fix the garbage collector, or (maybe) better yet, give user code a way to switch GC algorithms based on app-specific needs. Until then, the ability to manually manage memory is nothing to sneeze at.