That is a sandbox issue; obfuscating Javascript can get to really advanced levels.
If I remember correctly Google's reCaptcha work by interpreting encrypted instructions on an also encrypted interpreters that is Just-In-Time-Decrypted. Also it is entirely possible (and easy) to fully write an interpreter for wasm in Javascript. From an explot perspective literally the only thing that wasm provides is performance (hence the crypto bots).
The reason for vulnerabilities in Flash and Java was that the plugins were running in a different non-sandboxed (or badly sandboxed) process. The inability to inspect the Flash/Java binary was only relevant because of the many many bugs and exploits available in the runtime.
The reason being that both Flash and Java (and every other plugin) provided functionality completely absent in browsers (one example was the ability to open system-level network connections), this functionality was not sandboxed enough.
From a security perspective it was almost close to running `make install` instead of `ls` on a random project from github.
The reason people are confident in wasm security model is because it is almost implemented as a Javascript function that just manipulates ArrayBuffers.
There are currently proposals on the way to actually increas the reach of wasm code and allow a deeper level of interaction with the host environment, but (with the exception of threads) they all only offer functionality already exposed to Javascript