* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).
* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.
* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.
And yes, the lack of access to stack even affects C code. For example:
int i = 23;