It's likely due to memory mapping optimisations mentioned by @riking here: Wasm, wasmtime, wasmer: hacks for mmap, breaking 4GB limit - #7 by riking
If you map the VM's memory in such a way that the sandboxed code "physically"¹ can only express (offset) addresses of locations it should actually have access to², then you can both compile memory access without adding bounds checks and call into and out of Wasm without a context switch of any sort. This vastly improves performance in a platform-independent way.
I'm pretty sure it's possible to create an alternative implementation in a platform-dependent way using virtualisation features, but I haven't read too deeply into it.
My understanding is that it would take more effort to implement it this way. I'd like to hear if there are other limitations to that approach that I'm not aware of.
¹ The other way to take advantage of that would be to logically prevent programs from arbitrary reads (outside of anything that's clearly an array access, which would still need a bounds check) ahead of time, but as Wasm is mostly a "flat memory" runtime, doing this to a significant degree is very complicated and essentially limited to "known cases".³
² plus locations in unmapped pages, for which you can trap access in the runtime with little effort at zero cost
³ A truly general solution would solve the halting problem. Even with reasonably constrained programs, the search/evaluation space is extremely large and escalates exponentially.