[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.
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.