However, I think it would be possible to make systems in which similar instances, because they are written in a type-safe, memory-safe language in the first place, could bypass WASM and both start up fast and run fast optimised code.
I have done some research on portable bytecodes, and have some novel ideas for getting more performance, but I agree that the inherent problem remains. One thing that help make optimised C/C++ fast is that optimisers assume that undefined behaviour doesn't get triggered. But in a system for portable code, you can't just assume - you'd have to prove that it can not exist to be able to do the same optimisations, and that is far from straightforward. And when it triggers, it has to work the same say, or it won't be portable (bug-compatible) between hardware.
In fact I'm quite certain that whenever portability or security ran up against performance in WASM's design, that performance always lost. Those other two goals were definitely a higher priority for WASM's designers.
Stable, portable byte codes are always inherently lossy. Information that could be (and often is) useful to optimizers is lost in that conversion. Then the conversion from byte code to running code also is on the hot path - it's on the hot path of starting execution. This is the same problem existing byte code solutions face, like CLR & JVM. WASM didn't manage to magic a solution where nobody else had. It's the same thing that's been done to death, just with "web" slapped on the front of it & bundled in a browser. That part of "being in a browser" makes it interesting for web devs, sure, but in the broader context of "all of computing" it's... just not? It's what we already have had (and been using!) for decades.