I used to be totally anti-scene-graph, for much the reasons that Tom Forsyth mentions in his blog.
However, then I changed the idea of "scene graph" to one of "scene database," and it all fell into place. A database has a bunch of different indices, and tables, and whatever. A scene database has the same.
The argument about "optimal state changes" is specious, as Tom suggests. Anytime you change a single state, enough stalling happens in the hardware that you could just as well change all of them. In DX10, this is even made explicit, as you only set state by applying state blocks. However, the benefits from a scene database is not that you can sort for minimal state changes, but that you can get rendering away from game objects. This means that you can easily change things like your global illumination, or your shading, or whatever, without having to touch every game object.
Meanwhile, in a system where you call into the object and it does glPushMatrix(), glBindTexture() and friends, those kind of changes are much harder to make. Tom's blog against scene graphs is dangerous: for example it has been used by Ben Garney of Garage Games in reply to questions about the way rendering is set up in the pre-TSE version of Torque (which makes GL calls directly in the objects), and a reader who doesn't have all the knowledge of Tom or Ben is likely to draw the wrong conclusion from that.
The point is that once the object "owns" rendering, it will be tempted to do things like update particle systems, or animations, or other time-dependent state, inside the render callback. As soon as you do that, multi-pass effects like anything from dynamic cube maps to deferred shading become nightmarish. (Hacks like passing a dt of 0 for second passes abound)
You could make the argument that "objects shouldn't evolve state inside render" and "all objects should adhere to the rules," but that makes for a harder to program model, where the rules have to be made very explicit. And, even worse, when you decide to change the rules for some internal reason (stencil shadows, shadow buffers, deferred shading, what have you) then ALL objects need to be updated. It would be much simpler if only one or a few rendering strategy classes had to be updated.
A scene database where the object describes itself and its shading parameters, and the renderer then "does the rest" is actually a lot better. Yes, it's deferred, which Casey Muratori doesn't like for GUI rendering, but for describing a 3D scene, I believe that's actually what you want. I've come to this conclusion after doing graphics of various sorts for ten years, and after being a vehement scene graph opponent for eight, before starting to re-evaluate the base assumptions.