WebAssembly only uses the same web APIs as javascript, has generally been implemented using code already used for supporting javascript, and was designed from the ground up for this use inside the web sandbox, as opposed to Java which was designed in the same way as most language runtimes based around unsandboxed access to a system and then had a security layer grafted onto it.

#1 issue with applets was integration. Was it on the browser? Which version? How does auto-update work? etc.

Adobe did an amazing job of making sure Flash was there, and seamless. To the point people barely had an awareness.

Java Applets failed because Sun was a 'debating society' (per James Gosling). Definitely not a consumer oriented company, thinking about end user behaviour etc..

Other reasons as well, but that's #1.

Source: me, deployed a bunch of Enterprise projects on Applets back in the day.

operating from the premise that most applet exploits functioned by elevating a sandboxed applet out of its sandbox (no idea if thats accurate), perhaps because java applets had an un-sandboxed mode built in, whereas wasm is always sandboxed and has no equivalent to applet's un-sandboxed mode.

It's a bit tricky. I don't know if you can categorically say wasm is or will be more secure than applets. Both of them rely on a runtime that is more privileged than the code being executed, of course. Both of them can have runtime bugs that allow privilege escalation of various forms. There was a recent perma-root bug in ChromeOS and one of the exploits along the chain was based on exploiting a WebAssembly runtime bug.

If you look at Java's security track record in recent years, there's been just a couple of zero days in the past five years. That's probably a mix of genuinely better security and less attention due to being kicked out of web browsers. But if you go look at the security histories of other sandboxes like browsers or kernels, it starts to look pretty good. A new paper that just came out introduced a new Linux kernel fuzzer and discovered, I think, over 30 zero day exploits across several different Android phones. So ordinary UNIX style process isolation is pretty useless if you can reach device drivers from inside the processes. Even the quite aggressive and resource intensive browser sandboxes that browsers use routinely have escapes, often because they're always adding large new attack surfaces like WebAssembly, WebGL etc (all written in C++).

very interesting, did you read about the linux kernel fuzzer and the ChromeOS root here or elsewhere? regardless if you can provide a link either sound like very interesting topics.