AOT compilation really isn't required; sometimes JIT compilation is a real winner (like in those startup time cases Alon mentioned, but also in cases with constrained memory, like mobile) - sometimes 90% of the code in your app isn't going to be running most of the time, and it's much better to have 1-2ms pauses for things to be JITted or larger pauses behind a loading screen.
The AOT compilation for asm.js is arguably a win primarily because it produces deterministic behavior (existing heuristics in SpiderMonkey and V8 are an ENORMOUS PAIN) and because it enabled them to get their existing IonMonkey code generator to produce better output. Those both justify the effort, I think, especially given how cheap it was to implement.
All of those proposed features in your last two bullet points are useful for JSIL, which does not use asm.js. I can understand how people with a narrow understanding of JS look at these things and think 'these are all VM features for asm.js disguised as JS APIs!' because they don't understand, but they simply aren't. IIRC, Emscripten doesn't even benefit from Binary Data or Value Objects because it already has a virtual heap; that's not going to change.
With constrained memory, ahead of time wins by a long shot thanks to demand paging. You only need to allocate physical memory for code that is actually hit.
With JIT code, you need to allocate space for the bytecode, allocate space for the linking, relocations, or whatever substitute you use (since bytecode typically isn't prelinked), allocate space for the JIT itself, and allocate space for the JITted output.
Sorry, I should be clearer - the kind of AOT compiles that OdinMonkey currently does do not benefit from demand paging, because the entire app is compiled from scratch at startup each time. If it generated executables on disk, then you could demand-page them in, just like the output from a traditional compiler. But I don't know if that has been proposed anywhere.
I guess you could allocate guard pages for each function in the application and AOT-compile each function once on demand to simulate demand paging? Hm.
Emscripten certainly should benefit from value objects because they are required to deal with 64-bit integers and 32-bit floats efficiently.
Supporting asm.js as a compilation target for managed languages is very much a goal (according to the FAQ anyway), including binary data and somehow garbage collecting the same within asm.js. I think this includes JSIL eventually, but it doesn't really matter whether you call it asm.js or not: those features fall under the general umbrella of things that are only necessary for compiling high performance, statically typed code to JavaScript, which would become a fairly unimportant use case if the "correct way" to run such code was via PNaCl; thus, they can be considered a parallel technology stack to PNaCl. I personally think that since it's still a way smaller stack and for other reasons, JavaScript is the better approach, but I don't agree that this is all stuff that is orthogonal or going to be done anyway.
The AOT compilation for asm.js is arguably a win primarily because it produces deterministic behavior (existing heuristics in SpiderMonkey and V8 are an ENORMOUS PAIN) and because it enabled them to get their existing IonMonkey code generator to produce better output. Those both justify the effort, I think, especially given how cheap it was to implement.
All of those proposed features in your last two bullet points are useful for JSIL, which does not use asm.js. I can understand how people with a narrow understanding of JS look at these things and think 'these are all VM features for asm.js disguised as JS APIs!' because they don't understand, but they simply aren't. IIRC, Emscripten doesn't even benefit from Binary Data or Value Objects because it already has a virtual heap; that's not going to change.