> There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited.

It's not a DSL, it's a full on programming language. It's like claiming Action Script was a DSL, it wasn't.

It means tons of code in that language in order to create custom business logic, it means re-implementing things that were already written in tons of languages and so on and so forth.

So a new language makes sense but it's a trade-off.

Apparently there is the possibility of using other languages, so let's see if the integration is as robust.

https://godotengine.org/article/introducing-csharp-godot

Whether GDScript is a DSL is arguable; a game engine scripting language falls in the interesting middle ground between a special purpose DSL with a limited scope (e.g. awk) and a general-purpose programming language with tacked-on frameworks (e.g. C++ and DirectX).

There are important assumptions and specializations (e.g. the engine-managed game loop and attaching scripts to nodes) but also a large variety of use cases (for example both low effort and high performance graphics)