Scenegraphs themselves can be useful, but having them heavily tied into other systems is a no-go. All the scenegraph should be responsible for is concatenation of transforms - and thats a distinct process that can be done in isolation before culling even begins.
I'm not an expert on the matter, but from what I have read in recent articles, scene graphs are a no-go today. I would like some enlightenment on the topic too.
Not to confuse the issue or nitpick, but what you are describing is a hierarchical tree and not a graph. A hierarchical tree generally has only one meaningful way to traverse, (that is from top-down) and can therefor only be optimized for a single purpose.
A scene graph in the traditional sense is a multipurpose database that can be traversed in many different ways to visit nodes in different optimal orders for different purposes. The thing about "scenegraph" is that it has turned into a blanket term that gets thrown around and misrepresented. If you're just storing a tree to do transforms to/from world space, then you don't have a scene graph so don't even call it that.
They are not an obsolete concept and they did not die out with the fixed function pipeline, as I think is a commonly held belief. They are just as applicable today as they ever were, they just didn't turn out to be all that useful in practice and are really more trouble than they are worth.
On the other hand, if you were to embed an existing
graph database and actually squeeze some good real-time performance out of it, you'd have a potentially very powerful tool at your disposal. I just don't see the need, it's overkill in most cases.