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.