Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.
I'm not 100% sure about any of this (I've only listened to most of the video above), but I think the gist is that WebAssembly provides a compile target for applications, meaning you can pre-compile an application so that your source is downloaded essentially as machine code. Furthermore, that means your compilation can perform as many optimizations that you care for, because it's happening ahead of time (not on the user's machine).
Without WebAssembly, browser vendors have to strike a balance between optimizing the JS as much as possible (for increased performance), and running the script as soon as possible (so the user isn't waiting too long for execution to begin).
edit: Demo of this in-browser video editor charts a FPS difference between the JS and WebAssembly implementations.
https://github.com/shamadee/web-dsp
Is the "parsing" what is displayed as "compile script" in Chromes profiler? That seems to take almost zero time. For example jquery.min.js compiles in 0.1ms here.
Libraries like jquery are not the target use case for WASM. Its intent is to make large applications viable on the web, like something you'd normally install on your computer.
There's a talk by Alex Danilo from Google IO 17 explaining it in detail.
Here, I'll link you directly to the part where he starts explaining the differences on a technical level:
https://www.youtube.com/watch?v=6v4E6oksar0&t=11m24s
Another part is that I suspect it makes maintaining a good JS compiler easier, because all of that asm.js code can be removed. I'm sure the browser vendors are happy about that.