At Temporal we've done a lot of research on WASM-based deterministic workflows. While they make sense in a general way, they suffer a similar problem as deterministic OS environments (e.g. hermit) - safe updates. People often need to apply code changes and know they will be deterministic changes with regards to past executions.
When determinism is clearly defined at the language level, you can easily see when an alteration would be compatible with existing long running executions when replaying old history. However when it's at a low level, it's less clear.
For example, Go WASM includes its coroutine scheduler inside the WASM blob. A slight change in an unrelated part of the code can change the order of coroutines causing it to be an unsafe non-deterministic change when deployed for running workflows. Similarly, Go may make an external call to a seeded deterministic random for map iteration (yes, Go explicitly randomizes map iteration order). One other call to that random will make that map iteration order possibly different breaking replay.
So WASM is great unless you need to alter code for existing workflows that run for years. Then it becomes less clear, whereas language level determinism can have clear semantics to code authors and static analyzers with explicit versioning/patching if needed. Of course using lower-level languages can help here too since they are more predicably compiled with a smaller runtime, but they still require authors to be careful on code changes.