I too found it a bit cumbersome past a certain code size. A lot of games don't necessarily need a lot of raw or complex code to run though, so the 1st class benefits of GDScript start to shine, like the native debugger, autocomplete, Godot-specific accessor syntactic sugar.
Its hard to compete with an almost 25 year old battle-tested language, but given the domain and the team size, its a good product and worth pursuing IMO. With that said, I wouldn't want to give up the ability to have C# interop when I need it, and I imagine many games would need to be rewritten in C# after a certain point.
It's probably not ideal for large projects, but it adds huge value for small ones, and for people who are learning, and I'd expect probably even in larger projects if combined with C++, C# or Rust. It's miles better than the joke Unity had that was called Boo. I also like it a lot better than Blueprints in Unreal while still remaining extremely simple, although I can see how Blueprints can be better for more visual people.
I concur. I believe GDScript should be split from Godot itself and support should be added for third party IDEs. It has a lot of hard-coded things specific to Godot in it and it suffers from it. The built-in code editor has a very confusing layout and its built-in code editing functions will never be as powerful as providing a language server to a dedicated IDE.
Its hard to compete with an almost 25 year old battle-tested language, but given the domain and the team size, its a good product and worth pursuing IMO. With that said, I wouldn't want to give up the ability to have C# interop when I need it, and I imagine many games would need to be rewritten in C# after a certain point.