Should Godot adopt high performance Nodes ?

I think Godot's heavy reliance on inheritance was a mistake. This is most obvious when dealing with the scalability of physics bodies. The engine clearly does not like this, but permits it nonetheless, because all Node2Ds/Spatials have a scale, and all PhysicsBodies inherit from one or the other, and it works out fine for the most part. It works mostly great for things which need to be rendered (mostly sprites or meshes; most everything else, probably .) And it makes logical sense for anything to exist in the world to have a location, rotation and scale. Nodes, however, tend to be a little more abstract than that (how often do you find yourself scaling or toying with the light mask of AudioStreamPlayer2Ds?), not really conforming with physical items that you would expect in the real world, and just as object modeling often fails to make sense in general OOP, so does Godot's nodes at times.

One could argue the inheritance hierarchy could've been reworked; maybe not all Node2Ds need scale, you could have an intermediary Node2DScalable, and then those nodes which don't make use of scale (or go awry due to scale) could go without. It's a really awkward way to structure your code however (not to mention all the refactoring you'd need to do every time you realized you didn't want something in some class), and doesn't offer a lot of configurability for all the various combinations of different nodes you might want.

So that's where the whole ECS thing is meant to improve the matter, though that frequently falls into the same trap (to be frank, Unity's old system is very close to how Godot works now, and I imagine both engines were born around the same period of game development where this was the hot item.) It's even worse arguably for Unity, since every gameobject has the same 3D transform, no matter what it is; at least in Godot you have the option of going without, using the vanilla Node class. And then attaching components to gameobjects is not much different from attaching nodes to nodes. But even Godot's Node class is quite a hefty thing, as it's presumed that, if you're using a Node, you must also want all the features which come with each Node, when in practice, you may only be looking for a way to make some set of functions globally accessible, or to define some item in your game; you may not make use of groups or processing or signals or meta, though those will all be there for every instance. Granted, you should use a script of static funcs in the former, and custom resources for the latter, but I don't think these are commonly understood practices with Godot yet (nor very clearly supported.) And, in practice, it probably doesn't matter; hardware nowadays can definitely put up with the bloat for any game that doesn't demand intense amounts of processing power and resources (which is most of them I think.)

"Most games don't need that level of performance", however, doesn't sound as good as "super-efficient ECS blast processing job system", just like "Most games don't need that level of graphics" doesn't sound as good as "Beautiful state-of-the-art physically-based renderer"; sure, you, as an indie developer, can't really make use of those types of graphics very well in any case, but it sure does help in marketing your engine.

From what I understand about Unity's new system, it's more awkward to compose your game entities now, but works a lot faster after eschewing the various bloat associated with GameObject (it's also more like an ECS now, instead of the weird compromise that preceded it.) I think this is a step in the wrong direction: game engines should sacrifice processing power to make it easier for the developer to develop. Since hardware these days can easily handle it, you shouldn't be so concerned about processing power, your engine should be taking care of that for you already, and not impose annoying design decisions on you to pursue that goal (such as how I imagine a "high-performance node" would do); you should instead worry about the quality of your tools so that you can develop games swiftly, comfortably and effectively.

If performance is something you have to worry about for certain genres, you can always do away with Nodes and rely on your own data structures, accessing the engine's various servers directly, even just with a GDScript attached to a Node; there's a bullet hell example game floating out there made in Godot, which showed how to handle hundreds of bullets on-screen without using Sprite nodes or Area2D nodes for each bullet. I'm not sure how it can get much more efficient than this without just cutting down the amount of entities you really need at once, e.g. an army of 1000 soldiers could be abstracted into a single entity representing 1000 soldiers, or without applying that cache-miss trick when it comes to ECS, but in any case, it's probably not going to be your bottleneck. Great tooling should always be the #1 priority.

So, while I do believe there are various aspects of nodes that could be improved (though perhaps not without a huge overhaul of how the engine works on a fundamental level), I don't think those changes should be made to make games more efficient (perhaps even unnoticeably) at the cost of tooling; nodes exist to make game development easier at the explicit cost of performance, and I feel the "high-performance node" is paradoxical to this extent.

Indeed there is some code inside the node classes, but mainly getters and setters, very few algorithms here, except the scripts I guess. Look at the "scene" folder in the Godot source the nodes source files are here. The main loop iterates on resources. The OOP part of Godot may take a bit more RAM than a full ECS , but I think it's not the main performance weak point. Godot lacks some optimization techniques who can be implemented in every engine architecture.