You seem to be operating under a misapprehension of what a graph is, versus what a tree is. Relationships in one space (e.g. transformation heirarchy) does not need to have any relation whatsoever to another space (e.g. order and nesting shown in the GUI map editor; or inheritance of textures & shaders; or model used to render; or connection to the "sector/level" which an object was loaded with and should be unloaded with; etc).

A scene graph is a way of describing and defining the relationships between your objects, as a means of codifying and prescribing how you implement those relationships and objects... not merely a tree that happens to be notionally created by adding an `SceneObj *parent;` field to all your SceneObj's.

Graphs are hard to visually represent, but trees are easy. The UI doesn't make them easy to spot.

In Unreal's editor, you have access to a bunch of UI organization tools that are not part of the transformation heirarchy. Folders, Layers, Levels. With the exception of Folders, which are discarded at build time, you can iterate over those as easily as iterate over the transformation heirarchy. These are all parts of a graph which has nothing to do with transformation.

In UE4, at least, blueprints are composed of two varieties of components; those which are part of a transformation heirarchy, and those which are not. When you instantiate a blueprint, you're actually instantiating a statically-flattened version of that blueprint, all the way to the root blueprint inheritance nodes. If you have static meshes at several layers of the inheritance, for instance, and all set as Dynamic or Static, instead of Movable, they actually get baked into a single megamesh up to the nearest Movable point in the heirarchy (give or take batch size contraints).

All connections between objects are part of the scene graph; even when the editor doesn't provide a visualization for them. If in Unity or Unreal you set up a "Gang Boss" relationship between a bunch of mooks and their elite leader by assigning the leader object as the value of the myBoss field of the mooks, that's part of the scene graph, too. And either the engine or the mook's code will have to be able to handle the situation that the boss just got excised from the scene graph by a player's sword.

8 hours ago, KarimIO said:

EDIT: But isn't that made redundant by the use of flattening static nodes?

What Sacaldur and I are trying to tell you is that an organization tree and a transformation heirarchy tree are orthogonal concepts, that their definitions have no interrelation. If you choose to implement it by mixing them as heterogenous types of node in a single tree, that's your choice, but you might find it easier or nicer or more reliable or more performant or... to have them instead be two (or more) separate systems.

8 hours ago, KarimIO said:

I do like the idea of using static / dynamic / movable to dictate the use, but there still might be cases where you don't want a static object to move with its parent, which was organized in that way simply for semantic reasons

I fear you've misunderstood. That 3-way field is an optimization declaration, used by the engine to discover the boundaries of where it can do mesh/material combining and physics baking and such. It's related to the transformation heirarchy, but it's not a way to opt out of it; it's a way to flatten it by declaring what objects cannot be moved at runtime (relative to their parent's coordinate space).

There is no way to prevent a transformation-heirarchy child from moving with its parent (assuming you have a working transformation heirarchy), although you can compensate for it by manually adding an inverse transform to that child whenever you add a positive transform to its ancestors. Mind the cumulative error term.

Again; organization parentage is not transformation parentage. You will get a lot of mileage out of not conflating or combining the two.