There's an important difference in effectiveness when it comes to blacklisting APIs that were designed to be open rather than whitelisting APIs from within a closed system. There are tons of sandbox escapes that get discovered and patched each year, usually because of race conditions or the complex systems that the container APIs and general system APIs use to protect against each other. This is the reason why symlinks require administrator permissions in Windows, for example: the security model around symlinks is very complex and there have been tons of privilege escalation/arbitrary file read/write exploits just around something as conceptually simple as a symlink. Microsoft chose to restrict them to privileged users because they consider them to be too difficult to properly defend against.

A WASM executable can do nothing but allocate memory and change the contents of such memory. There's no I/O, no socket state machines, no kernel communication, it's all just numbers in, numbers out. Even something "simple" like entering a string into a WASM program involves treating that string as arbitrary memory to be operated on by the WASM runtime and things like structs, pointers and classes must go through several layers of abstraction before they can be used.

From this numbers-in-numbers-out mechanism further standards are currently evolving, standards that allow exposing callbacks and other such APIs into the WASM code. There's still an abstraction layer between the two, but the runtime can now allow the code to do a bit more.

I'm not too fond of the way these APIs are turning WASM into "Java but Javascript" but it's still good to see the security first approach to WASM runtimes that won't allow the code to do anything they don't provide rather than to allow everything except for a subset of functionality. The default model of modern operating systems is "you have all permissions, except these" rather than "you have these permissions and may ask for more". Trying to use seccomp and syscall filtering in Linux is a terrible experience because it's hard to know for sure that you've set up every possible limit you can in order to neuter exploits.

To see the benefit of this approach, look at the sandboxing in mobile operating systems like Android. Earlier permissions weren't a good fit for application developers and over time they've evolved. Google has had to patch in more and more limitations to prevent malicious behaviour like tracking (except for their own tracking, because Google). They've lifted some restrictions, like the INTERNET permission being granted by default in practice, but most of their API changes have been centered around taking away application functionality and providing a more restricted alternative.

Now, I very much like the option to root my phone and do whatever the hell I want on it, but I don't want the random crap the local weather app's advertisers try to force down my throat to have too much of an impact on my phone.

Personally, I tend to install PWA versions of web apps rather than download stuff from the Play Store if I can because I don't want these websites to have that much access to my phone (and often they're just wrappers around websites anyway).

With WASM, C's problematic memory management isn't as much of a problem. Your program can crash, show weird text, do anything weird you can think of, but it can't jump to kernel mode or escape the sandbox without a very significant flaw in the runtime whitelisting code. Redirect the control flow of a WASM program that can only serve web pages and control the files in two specific paths and you're practically nowhere. You can probably read some files but there isn't even a guarantee that you can upload the contents of the database anywhere, because networking is opt-in!

For most people in most cases I would very much prefer to keep running on bare metal myself. Safe programming languages are great and much more capable of being optimized because WASM itself is two compatibility hacks stacked on top of a Javascript library; it'll take a while for the format to be competitive and even then it won't compete with Rust in terms of performance.

However, the inexplicable urge to move to vendor lock-in through stuff like Amazon Lambda and the mistaken idea that every application needs the complexity of Kubernetes for some reason are undeniable. Within these contexts, I can see the benefits of what WASM people are trying to achieve.