Guaranteed termination isn't the only analysis worth having, especially since if your aim is termination (as opposed to leveraging that simplicity for other analysis) it's much easier to simply impose termination and be done with it.
By it's very design it's aimed at running untrusted, even malicious code without exposing the host to security risks, while allowing the imposition of resource constraints. It doesn't sound completely absurd to me (not an expert in this) that some project might seek to use those safety guarantees as a way to avoid paying for the more heavyweight guarantees provided by the kernelspace/userspace split.
A quick google find lots of people trying to get this to work; who knows - it might pay off.
So, WASM isn't entirely unconstrained, and those constraints do allow some interesting analyses that true native code cannot support, e.g. symbolic execution: https://blog.trailofbits.com/2020/01/31/symbolically-executi...
By it's very design it's aimed at running untrusted, even malicious code without exposing the host to security risks, while allowing the imposition of resource constraints. It doesn't sound completely absurd to me (not an expert in this) that some project might seek to use those safety guarantees as a way to avoid paying for the more heavyweight guarantees provided by the kernelspace/userspace split.
A quick google find lots of people trying to get this to work; who knows - it might pay off.