It's a lot clunkier than Unreal. You'll have to build a .so/.dll using scons or cmake (good luck finding a CMakeLists.txt that actually works) and you have to register all types manually. You will also not be able to work around the issues with the APIs mentioned in the article around dictionaries AFAIK. There is no header tool and no autogenerated code for your classes. Oh, and reloading the DLL on Windows requires an editor restart. Plus I haven't found a good way to debug load failures either apart from starting the editor from a console window.

I ended up sticking to GDScript in the end, but the typing system is very basic and the code can get very messy quickly. Plus, as far as I could tell, there is a race condition between signals and the process function, but I need to debug that more thoroughly to be sure.

TBH if i was making a game using Godot i'd just be modifying the engine itself to add any "heavy" functionality (the nodes system would most likely help here) and expose custom high level APIs to GDScript. IMO scripting languages should be used to script the behavior of a game: i.e. tell the engine what to do, not how to do it (which should be written in native code).

From the subreddit submission about this blog post (linked in the post itself) it seems this is something some people already do.

The GDExtension API seems something to use only if you want to write C++ extensions/plugins to be usable by other people, but i don't see much of a point in restricting yourself to it if you are making your own games.