By comparing to fly and sandstorm it sounds more like you're looking to solve the application hosting problem. How is that a problem solved by wasm? It's just a bytecode format and runtime, it doesn't deploy servers and load balancers. The only thing I can think of is that users build wasm binaries/containers and don't care whether the hoster uses x86 or ARM or RISC-V.
Exactly what you said, plus one more important opportunity (for the distant future): by being architecture-agnostic, the images of running WASM processes can freely travel between the nodes of a cluster, thus providing remote "exec", "fork" and roll-over capabilities. This can transform the way we create distributed software; instead of remote APIs, "queues", "buses" and "workers" we will be able to use the very same primitives we already use for in-proc and inter-proc coordination. So, the whole service like YouTube with transcoders and everything can literally be represented by just one or several executable files in a folder.
The biggest issue for cloud hosting/self hosting is sandboxing arbitrary hostile code. This almost always requires expensive KVM-based hardware accelerated virtual machines. AWS firecracker is the same shit as hardware accelerated VirtualBox, just heavily stripped down to allow for rapid booting. WASM comes from the CloudFlare functions/V8 ideology where a language sandbox is sufficiently locked down, such that you don't need heavy operating system level virtualization.
This way if one application gets compromised, it won't result in the entire physical server being subverted.
With a sufficiently complete environment like wasix, you don't even need the rest of the OS or even a kernel. A filesystem and a networking stack is all you need. Just load a unikernel from network boot and you are good to go.
