It is incapsulation of code into a sandbox. You can do it by moving code into user-space and use hardware implemented sandbox, or you can do it by making your own sandbox in software.

Hardware implementation runs code faster (kind of "executes more instructions per second"), but switching from user-space into kernel-space and back are costly. The costs are very high, high enough to projects like "user-space TCP/IP stack" start popping up: it is all about avoiding switching to and from kernel-mode.

Software implementation of sandbox in the kernel allow costless (or near costless) switching of context, but runs slower. It is tradeoffs, and not every one piece of software would benefit from moving into kernel-WASM, but some would do.

It's sometimes useful to run "arbitrary" code in the context of the kernel. For a concrete example look at the Berkley Packet Filter[1]. In it's original usecase it allows packet filter expressions to get compiled into a bytecode, which in turn get verified & executed in a kernel-space virtual machine. This is useful because it allows the user to implement arbitrary expressions, in this case firewall rules, but have them executed in the context of the kernel. When you're trying to filter millions of packets per second, or instrument operations that are measured in sub-microseconds, avoiding that context switch matters.

[1]: http://www.brendangregg.com/ebpf.html

Security. WASM is sandboxed by design.

Many things are "sandboxed by design." Few things are true sandboxes.

I'm very skeptical of the idea of throwing out virtual memory and process isolation to depend instead only on software sandboxes.

That and performance. System calls have a lot of overhead when running in user space. You can dodge that when running as part of the kernel.