GDScript is purpose-made for the task of being aware of how the engine wants to bind data. That is, its type system knows what the different components are, the events they can send, types of assets, etc. That makes it much smoother in terms of IDE support than using a general-purpose language - it helps you along with stuff like cueing an animation or audio event.

It's not really a language meant for lots of computation, but that isn't actually what most gameplay code needs: games are generally doing something based on a lookup table, finite state machine, or collisions. It only becomes a deep issue if you've got a lot of custom simulation going on.

I was in the camp formerly of "just use Lua/C#/JS/etc." for Godot as I didn't want them to reinvent the wheel. I've changed my mind on the matter after using it though. Or, through having a custom implementation, they've integrated it very tightly with Godot's node/refcounting memory model. Much in the same way UE's Blueprint execution feels similar to C++ logic, manipulating nodes and sending signals in GDScript ends up having a similar flow to something done lower-level in the engine.

I think it makes a tighter experience, and less maintenance work is done for bindings and transferring data to/from a separate heap/runtime for scripting.