How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++?
The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me.
As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive the behavior.
But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.
Hearing people dismiss the performance of something as basic as a raycast with "well just code in C++", while many people (including this founder) say that Godot focuses on simplicity sounds counter-intuitive. So is GDScript a lie for anything slightly intensive (and again, raycast. I'm using "intense" in the loosest of words) and I should simply make my whole game an engine module? But I keep hearing that "I should just try GDScript it's really easy and you come around to it!"
Feels like a motte and bailey.
There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior.
And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong.
The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back.
But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.
You may even invert direction, handing over a pure script language function (no context) + the data, so the c++ engine may crunch the data at least in parallel small script vms without stack, similar to a shader.
Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement: