- My bro had written RTS prototype using built-in tilemap. When zoomed out, game was working pretty slow (12-20 fps) because drawing a lot of tiles at once was bottleneck. He was able to optimize his prototype using GDScript to work with stable 60 fps (he cached rendered tilemap as texture). - I wrote simple "terminal emulator" control for Godot. It was quite slow - rendering 125x32 characters terminal was 120 ms per change. With few simple tricks I reduced it to 40 ms for full redraw and 1 ms for small change like drawing few characters.
I dont know if you can configure the framerates and engine internals here.
Next problem is that you need to write a lot of partially performance intensive game logic code (pathfinding etc.).. which again makes sense to write in the engine native language.
There is a reason why game specific engine exist- and if i would dev a new game today, i would choose- the one os-game that is allready as close as possible to the idea port that to a dedicated engine.
Its way too much work to fork a generic engine to a high-performance specialisation.
I do think Unity is beginning to jump the shark a bit with what seems like a stronger focus on ancillary services rather than their core offering.