this is about a discussion called "scene graphs still useful?".
i think it is quite interesting. i didn't manage to find it in the sourceforge archives (for some reason recent posts are not archived) so the best i could do was to make a pdf out of my mails:
http://moenia.sourceforge.net/doc/discussion.pdf
very interesting!
Some intresting points, but as mentioned early on in the topic, most scenegraphs do not "traverse and draw" anymore. Neither does jME (we sort before we draw, TRANSPARENT and OPAQUE). And now jME also has the concept of things like render passes, moving further away from the scene graph discussed there.
Eg. the original article sais a coffee mug on a desk is not a desk so there's no point in using that information for rendering. But it's still on the desk, if you use a simple lighting model it's easy that the light that hits the coffee table should also hit the mug, etc.
The arguments given there are that traversing a scenegraph is expensive and you're better of doing precalculated or pre-guessed ordering, but in reality scenegraphs are often a quit cheap and effective way of doing just that (think of hierachial frustum culling for example), and you can optimize your scenegraph (eg batches). Of course there are situations (eg. indoor) where there's better methods, but it's no problem to use those with jME too.
Why is it called a scenegraph instead of a scenetree anyway? :? Every single one that I've seen has been a unidirectional acyclic heirarchy, a la a tree.
well yes, the original blog article is (almost) totally against scene graphs and should not be understood as ultimate truth . but the discussion itself is interesting and some experienced developers give their opinions on scenegraphs. the idea (the way i understood it) is that one shouldn't rely only on scenegraphs, but use other methods where it's possible and meaningful.
the discussion continues and it is now available in the sf.net mailing list archives (maybe with some delay, i'm not sure as i just got online).
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
@white flame: trees are graphs. by not calling them trees you leave the possibility open that there might be connections between the nodes of that tree. by connections you might understand whatever you want, but it's something nodes have in common 
(this is actually a joke. i don't know much about scene graphs. the only one i know a bit is the jme scene graph)
yes, i thought about thats too. it actually only depends on what you define as "connection"(or edge). if you just think of connections in terms of graph traversal possibilities, then the light is not a connection but just a shared element (like you would share textures). there were some debates about this topic on the mailing list too.