[T]he API surface area is that of the Web platform (e.g., WebGL for graphics) and thus WebAssembly use cases will contribute to driving forward the whole Web platform.
The inventor of javascript, Brendan Eich, writes in his blog entry covering WebAssembly about the polyfill plans:
It’s crucial that wasm and asm[.js] stay equivalent for a decent interval, to support polyfilling of wasm support via JS. This remains crucial even as JS and asm.js evolve to sprout shared memory threads and SIMD support.
He further writes:
Yes, we are aiming to develop the Web’s polyglot-programming-language object-file format. [...] wasm should relieve JS from having to serve two masters [FAQ entry here].
Most likely due to Mozilla's envolvement, WebAssembly even tries to address the "binary" barrier built up when dealing with WebAssembly on a client.
The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.