Of course it's a matter of perspective and I can totally get how one would be happy with GDScript. Tbh, it's hard to beat GDScript when it comes to making small games. It's quite evident that only GDScript has first-class integration into the Editor, C# comes second and all the other serious language bindings come third.

I might state the obvious here, but static typing, null-safety, being able to refactor and such things make C# much much better for bigger games. Slay the Spire 2 has been made with Godot + C# and people have already decompiled and peeked under the hood (for example here https://www.youtube.com/watch?v=SpB4-W9L4ec) and imo it shows quite well how certain patterns simply require a more powerful language than GDScript or would at least be very painful and fragile to make in GDScript.

Your workaround for shader stuttering sounds quite hilarious :D I don't mean it's bad. It seems pragmatic in a good sense. But yeah, it's those limitations that pile up when making Godot target the web...

gdscript is missing basic features like interfaces (only abstract classes with no multiple inheritance) or custom value types. spawning scenes from code is tricky and not type safe. asset loading and globals are a mess. the engine is built around using a lot of nodes but nodes are expensive, so you need to drop down to confusing low level server apis if you have performance issues.

the worst part is theres no defined build step so `@tool` scripts run both in the editor and at export time. its easy to accidentally crash the editor or mess up your scene with a bad editor script missing one line of code. and as far as i remember its impossible to undo so remember to save often.

godot is still the best option if you want a open source engine for your game but only because bevy is not production ready yet.