The main thing is that browser makers can implement it on top of their existing JS engines at relatively low cost, and the language model is basically just C so there's no difficult consensus building. In other words it's expedient for the browser guys, given that Mozilla killed all prior attempts to do things like NaCL, there was also an earlier initiative to teach V8 how to run JVM bytecode that got killed off by the same problem. Mozilla just systematically killed off any attempt to non-JS stuff. WASM sort of snuck in via the backdoor using hacks like Emscripten and asm.js and Firefox was losing market share, so WASM is what we ended up with.
Outside the browser as the other comments say it's about sandboxing primarily, and the feeling that it's not too dependent on a single vendor. Of course that means not much useful code runs inside WASM. The hard bit about sandboxing is not actually doing it, so much as allowing a usefully flexible set of permissions and features for sandboxed code.
Interestingly, Graal is also developing a sandbox. And with native-image you can compile the language implementations down to native code. So you could soon (even today actually but it's not really advertised) load a sandboxing JS or Python or Ruby or indeed WASM implementation from a shared library using a simple C API. Again though the hard part is actually that "real" code tends to have extensive OS dependencies. The JS ecosystem finds wide usage partly because so many modules are written for the browser which allows very little, whereas in the Python/Java/etc ecosystems modules frequently will assume things like filesystem access.
Outside the browser as the other comments say it's about sandboxing primarily, and the feeling that it's not too dependent on a single vendor. Of course that means not much useful code runs inside WASM. The hard bit about sandboxing is not actually doing it, so much as allowing a usefully flexible set of permissions and features for sandboxed code.
Interestingly, Graal is also developing a sandbox. And with native-image you can compile the language implementations down to native code. So you could soon (even today actually but it's not really advertised) load a sandboxing JS or Python or Ruby or indeed WASM implementation from a shared library using a simple C API. Again though the hard part is actually that "real" code tends to have extensive OS dependencies. The JS ecosystem finds wide usage partly because so many modules are written for the browser which allows very little, whereas in the Python/Java/etc ecosystems modules frequently will assume things like filesystem access.