For the time being, we have the option to disable WASM via firefox prefs
javascript.options.wasm = false
FWIW, firefox52-esr ships with this pref set to false.
I am not mentioning the above to be dismissive. I too am very mistrustful of the way-beyond-browsing inbuilt components and their capabilities. WASM though, in and of itself, I don't regard it as being especially worrisome. Right, wrong, or sideways... the inbuilt google-authored (FileOpen) filesystem browser is more worrisome. That smacks of NaCL -- native client -- as mentioned in millpond's post.
Looking ahead, I expect that by year's end we will notice quite a few "broken" sites if we run with wasm set disabled. Not just sites that will _need_ its functionality, but sites that serve content conditionally, based on user-agent. If "modern" browser version is detected, we will be presumptively served latest/greatest rather than a fallback version of content pages. I'm already noticing this. Example: when I visit a github project page and click "Graphs" then "Network", I'm presented with an eternal spinner image instead of a graph. I suspect this is probably due to my having disabled "features" like webworkers, websockets, etc. If I fire up old firefox v24 or TorBrowser 3.6.x and visit github... the graph renders just fine. I have not attempted to visit using ff52 while sending older versionID via spoofed request headers; doing so might be an interesting test.
If indeed this new bytecode is only supposed to run in VM jails, then what is its purpose
Predictably, the mass media articles are both sensationalizing and dumbing-down the presentation of "what is wasm". Its purpose is to be device-agnostic, platform-independent... and to provide a datastream which is more easily/quickly (by an order of magnitude, or more) processed by the app. Whether or not the component(s) processing wasm -encoded data is jailed, that's an just implementation detail.