1 - The best timeline: WebAssembly keeps its strong capabilities based security model, which requires explicit granting of resources to code inside the sandbox. This is great for security, but it requires giving up full access to the file system, and other I/O... which requires rewrites of things. This will, in turn, mean that many workloads won't shift to WebAssembly
2 - The worst timeline: WebAssembly repeats the mistakes of JVM, and eventually succumbs to the demands to allow full access to all of the resources of the host system, defeating capabilities, and making it a new JVM. Thus, it's not as safe as a VM, why would anyone use it? So, most workloads don't shift to WebAssembly.
[Edit/Append] WebAssembly uses a capabilities model of security. You have to explicitly give it access to resources from code outside of the sandbox, which are then passed (like file handles) to the code running inside the sandbox. This completely and securely prevents the code inside the sandbox from causing any undesired side effects in your system.
Think of it as handing someone $5 cash to make a purchase. You can't lose more than $5, no matter how confused or wrong things go after that point, you've limited the side effects to that $5.
Or think of it as plugging in a device to an outlet with a 15 Amp circuit breaker. No matter what you do, you won't draw 100 amps through the outlet, nor take down the grid (like the power in the old TV show Green Acres).
This is different than "capabilities" on a smartphone, which are "allow location access" or things like that, global, non-granular access to big chunks of your system. There is no "allow access to your file system?" flag in WebAssembly. In the best timeline, there never will be.