I suppose that depends on your definition of ugly. Godot focuses on ease of use as a design philosophy.
From a functional processing speed standpoint, both Node and Resource inherit from Object. Both are created with specific jobs in mind, and both are optimized in C++. From a memory standpoint, Resources are slightly smaller. But that size difference is rather miniscule on a modern computer.
I switched because I found using Resources to be cumbersome from a design and maintenance perspective. This is what my StateMachine looks like today.
As I’m creating new states, or tweaking old ones - it’s very easy to find and tweak the attached script in the editor. If I want to know what states are there, I can literally just open up the node and look. Also, because a StateMachine operates on the object it is contained within, it often needs references to other nodes - and creating references between nodes is very easy.
I have implemented a pull method for my StateMachine, so I can enable and disable functionality by adding or removing nodes. If I remove PlayerStateWallJump from the above StateMachine, it monitors states entering and exiting the tree, and activates or deactivates them as appropriate in-game. So if I’m making a game where I want to add such an ability as a powerup, I just add it to the tree programmatically.
It also means that I can add @export member variables for each state, and I don’t have to go digging for them - which increases speed of use in the editor.
I had been using Godot with GDScript for a few years, and I couldn’t answer questions on the forum here about C# as well because I’d never used Godot with C#, even though I had been using C# professionally for years. So, I took a course in C# for Godot and built a game (Dash and His Ghost Girlfriend) for a game jam to get the full experience. That course introduced a resource-based node machine, which I really liked and wanted to leverage in GDScript going forwards.
Yes and no. One of the primary reasons is it takes MUCH longer for a C# game project to load, and compiling before each run is SUPER time-consuming after using GDScript. That’s the limitation.
But the other reason is a reduction in limitations. When I first started using Godot in version 2.5/3.x, C# was faster at processing certain things. Now, GDScript has been optimized so heavily that it actually meets or exceeds C# in many areas when it comes to speed when running games.
I also always prefer to work in the language that something is written in. That’s a personal preference from years of being bitten by libraries supporting other languages for a library being updated with new features later, or not at all. Something that the Godot team is valiantly trying to rectify in 4.6 - but something I don’t have to deal with in GDScript.
As I got more used to Godot’s design philosophy over the past year, I realized that a Node-based StateMachine gave me a lot of useful built-in functionality that I didn’t have to code. It also just made for a better user experience.
I’m tagging @wchc who might have some thoughts for you as well.