process-based sandboxing has hardware support and thus stronger defenses against things like spectre. So far every CPU on the market has only elected to address spectre as it relates to crossing ring or process boundaries. Nobody has added hardware spectre defenses for in-process sandboxing. Also, process-based sandboxing allows the guest to also have a full suite of security protections like ASLR. If you are doing sandboxing for defense in depth, reducing the security of what's inside the guest in turn reduces the security of your entire chain.

And I didn't say the performance penalty was because of sandboxing (although in the case of WASM there is cost as it's doing software enforcement of things that otherwise are "for free" in hardware), but just that WASM has a performance cost compared to native. If you are using WASM just for sandboxing, you still then pay a performance cost for portability you didn't need.

> How is process-based sandboxing stronger?

Because the guarantees themselves are stronger, process isolation is something we have decades of experience with, it goes wrong every now and then but those are rare instances whereas what amounts to application level isolation is much weaker in terms the guarantees it that it provides and the maturity level of the code. That suggests that if you base your isolation scheme on processes rather than 'just' sandboxing that you will come out ahead and even with all other things the same you'd have one more layer in your stack of swiss cheese slices. A VM would offer another layer of protection on top of that, one with yet stronger guarantees.