I wonder: are these inefficiencies only relevant when using C# as your code base?
I mean, does all this talk about the "binding layer" being "structurally built to be slow " apply to those using GDscript?
Because I remember that years ago, back when it was decided to go with a custom designed language (GDScript), the justification put forward was that it would actually be more efficient to do it that way. So it would be kind of ironic if now the API from GDExtensions allows for more efficient bindings than GDScript.
But if it's only talking about the C# bindings... then the complaints are kind of missing the point. If you truly want to move from Unity to Godot properly, I would expect learning GDScript would be the more advisable direction. Specially at the moment. Godot's C# API and the new native interfaces are not really very mature, they were not the intended main way to use the engine... they are more of an extra convenient feature on the side that you can experiment with. In fact I believe they were recently heavily reworked in v4.0
Of course I understand that those coming from Unity would be more comfortable with a C# API, and I agree that it would be a nice thing if the C# API was just as efficient as the GDScript API, but that's not the same thing as implying that moving to Godot doesn't work because it's "built to be slow".....