FWIW from the comments i've seen on Reddit it seems that some of the reasons he brought up for wanting to do so many raycasts are already covered by Godot's functionality (in C++).
Also IMO unless you want to share C++ plugins with others (via GDExtension), if you are making a game with it you'd want to modify the engine itself for any non-trivial functionality anyway. Again, the situation he describes sounds like it would be much better done by writing the reusable controller itself as a node written in C++ inside the engine itself (not via GDExtension) that uses the fast physics API directly.
Basically what he describes is an issue only in specific situations and not something that would really stop someone from making their game.
I read that thread too and he just seems like a bunch of people denying there's a problem. The sibling reply here rather contradicts your point as do several others replies in the Reddit thread.
Yeah, it's true that raw performance doesn't seem like a major priority for the Godot community. If it was, GDScript probably wouldn't be the default language. There also seems to be a lot of defensiveness around GDScript's weaknesses.
Personally, I found that signals were very slow for communicating node to node, was dropping information because it could take longer than a frame.
Also IMO unless you want to share C++ plugins with others (via GDExtension), if you are making a game with it you'd want to modify the engine itself for any non-trivial functionality anyway. Again, the situation he describes sounds like it would be much better done by writing the reusable controller itself as a node written in C++ inside the engine itself (not via GDExtension) that uses the fast physics API directly.
Basically what he describes is an issue only in specific situations and not something that would really stop someone from making their game.