Running existing software in some convoluted browser-based environment, and giving a worse experience in most ways, doesn't really seem like innovation to me.
I think we could say it was pushing the envelope if the browser experience was superior to the native experience in every or almost every way. But that just isn't what we're seeing with these demos.
Of course, on the other hand it is inferior in many ways. It's just another option for game creators (and other apps too). For some it will be useful, for others it will not, just like consoles are useful for some but not for all, tablets are useful for some but not for all, etc. etc.
asm.js executes according to the ECMA-262 semantics, which are the full dynamic semantics of JavaScript.
This doesn't mean to imply the subset is the entirety of C; it means the subset is part of the definition of C — just like you can say "'int x = 4;' is C", even though it's a (demonstration of a) subset of C.
The JavaScript which happens to be optimised under the name "asm.js" is still JavaScript that executes in any non-optimising runtime, and the semantics with those optimisations and without are the same.
For the consumer it should be no different except they have an easy url to get to it, maybe saves are a url and there is a bit more security in theory if it is through a plugin that is widely used or tool that is widely used (asm.js).
Really this has tried to get going multiple times and really should have. Flash games were huge, Unity web games are coming up. Shockwave games back in 2000ish started it. Being open this is even better because maybe we can see WebGL gaming take off on mobile. 3d games in the browser have changed over time. Quakelive is going desktop client because browsers changing or removing NPAPI for PPAPI (http://www.quakelive.com/forum/showthread.php?34313) so maybe this is a good time to go the asm.js/emscripten route as plugin support is getting disrupted.