I've been at it for a few years now and my experience with game engine scripting is that the functions are small, and that it's helpful or pleasant to have the ability to make many calls back into the game engine to ask for things, even simple things. My measurements have shown time and again that libriscv spends 3ns entering and leaving the emulator dispatch, and 2ns to execute a system call or even a more complex host function scheme (using custom instructions).
So now it's a race. For example, wasmtime needs 48ns just to enter and leave, and 24ns to make a call into the host. That's around 100-150 instructions libriscv can execute before wasmtime has even overcome the fixed call latencies. And then add 50 each time we make a call back into the engine.
Now combine this with my ~200 host functions in my game, and I don't know how many in-game events. Which function would wasmtime be faster at? I don't know, probably not a single one. And that's really it. There's no fibonacci computations in game engine scripting. It's just logic.
As far as using complex run-times for scripting: I've already been doing this dance for years now. For example, TinyKVM is a native performance KVM userspace emulator that I among other things ran v8 inside. You can find my research paper about it. So it's not like I couldn't throw v8 in there and slideware some JS solution. But, I really do prefer writing C++.
Also related is attack surface. libriscv is 10k LOC. wasmtime is what, 350k LOC?
Here is a random function I benchmarked: https://fwsgonzo.medium.com/a-sandboxed-rainbow-function-b42...
wasmtime spent 107ns and libriscv 57ns. Those kinds of functions is your average script function. And, even if we were exactly matching in latency, I would still call that a win!
EDIT: To add, you did make a good point about tooling, components etc.