They compile from source code elegantly, sure. But you don't always have the source code available. Removing implications of the underlying platform makes it easier to change out hardware in the future. It's so that once the next Intel bug comes out, you can just shed Intel CPU's in favor of ARM, RISC-V, or even big-endian POWER.
Go also doesn't cross compile with cgo that elegantly. Having the platform run the output of C compilers means that you can remove that from your runtime assumptions as well.
But most of the examples in 'fulafel's comment already don't require recompiling for a new architecture. Node, ruby, Python, JVM languages... You just need a runtime for the desired architecture, which is still true for WASM.
(As a sidenote, POWER has supported either endianness for a while, and ~everyone runs Linux in little-endian mode.)
Given that the point of cgo more or less is to enable calling into C code, don't you still need to do a lot to make that work in WASM? Like cross-compile all your C dependencies to WASM, then use cgo to interface between the go things and the c things within the WASM runtime?
Pretty interesting ideas and I'm interested to see how it plays out, but tbh I think I'm too old school for all this newfangled stuff and would just use qemu.
Go also doesn't cross compile with cgo that elegantly. Having the platform run the output of C compilers means that you can remove that from your runtime assumptions as well.