We make a sandbox (in this case a very inefficient one) -- we assume the sandbox is the only way to deploy software, but mostly it's not because there will be times you need more than the sandbox or the software doesn't work, and then you're running "privileged" WASM routines.
The sandbox itself might even require some kind of leaky behaviour, such as accessing files or shared memory.
The wheel keeps turning. Some new sandbox will come along.
A runtime overhead that slows everything down to 1.5x, even with low hanging fruits is only going to accelerate this issue.
From a consumer perspective: We all act as if everyone has 8-16G of ram, because that's what we're used to, but the reality is that the majority of people have 2-4G of ram, even these days. That's not counting the anemic CPUs that are often inside awful cooling solutions.
From a server perspective: we outsource our Ops to cloud providers and pay a significant premium for computational speed, which means things like runtime overheads have direct costs.
The reason I called it inefficient is because it's not adding anything we don't have, it's just "another layer" with a large runtime overhead.
And, anyway, I'm mainly referring to this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death...
Even better, if WASM takes over the world, you can bake parts of it into hardware and remove a lot of other bottlenecks.
And it doesn't address any of the issues here anyway. As soon as you bind libc to it (or any other system library), which isn't exactly unlikely, you're right back into the problem of not knowing what the selinux policy should be. And you still want selinux policies since WASM is only a memory sandbox, not a permission sandbox.
That's pretty much where snap ended at, isn't it?