A massively simpler frontend than JS itself — it's closer to, well, assembly :) while JS is a dynamic language.
What we get in return is very very close to native execution speed for all the performance-sensitive things you might want to run on a computer — game engines, crypto, compression, codecs, etc. — in a sandboxed and portable way. One executable for everything from the typical Windows/amd64 desktop to your NetBSD/mips toaster, potentially.
Right now the chain is: Developer writes code in something like Typescript that then is translated to Javascript and then is downloaded by the browser (huge downloads compared to binary code). The browser then needs to parse that huge amount of javascript code to compile it into a bytecode that can then be JIT executed or interpreted.
With webassembly it would be as follows:
Developer writes code in the language of his/her choice, that then is compiled to a small bytecode. This bytecode is downloaded by the browser and then it is JIT executed or interpreted.
It is simpler, more flexible, and potentially faster.
There's countries in the world that still use IE6, and that's comparatively an easier transition :)
Also, as has been mentioned by others, WebAssembly could perhaps evolve to take a greater role, leading to a greater potential impact of performance gains.
Finally, if the complexity does in fact outweigh the benefit, the idea would eventually fade away. So far it looks promising. Time will tell.
These are already old numbers, and section 7.3 says 33.7% more efficient. Were one to run updated numbers, and use more than Chrome and Firefox, I'm pretty sure the numbers would be better still.
I note that the comment in 7.3 says the biggest speedup vs asm.js is in validation, so I assume this means the measurement includes startup. This advantage is easy to concede to WebAssembly due to its design.
In particular, I haven't looked into validation. JSC doesn't treat asm.js any differently than JavaScript, so the comparison would be different as well.