The interesting bit is that in addition to scene graph engine, "QML" is actually two slightly different but overlapping things.
First - QML is a set of javascript bindings to manipulate the native Qt widgets. In this regard it's a bit like Delphi mixed with Smalltalk. You can build and rewrite the UI scenes, using javascript as just the glue language. The more logic is built into the native widgets, the less javascript code will be required for actual UI implementation. (QML requires QtScript, which builds on top of V8. So for random javascript code execution, it's reasonably fast.)
Second - QML is a declarative scene description language, not entirely unlike CSS. You can embed javascript code to handle dynamic UI updates, which is pretty neat for simple interfaces, and quite nice for prototyping. For anything which requires high frequency and reliable low latency, native widgets are still the way to go. Yes, you can write your own custom widgets; Qt 5.x provides proper development headers so extending the framework is easier than in 4.x days.
Technically the scene graph and QML parts are separate. There is quite a bit of history in how the implementations lived and diverged: from a single "declarative" engine to first integrating a scene graph backend, to eventually splitting the QML implementation(s) into their own higher level modules.
Disclosure: I had the privilege of working for very propeller-head style Nokia projects where we had direct exposure and visibility to how Qt evolved from its 4.7/4.8 form to the current, modular 5.x rewrite.
Right, but at least as far as I know, currently a window manager trying to do compositing in Linux has to fight with X11 to achieve that, because it was not really designed to support that use case. Which is why Wayland is getting traction I guess.
OpenGL originated from the X world, for better or for worse, so I doubt there's much fighting going on. Any modern OpenGL is pretty separate from it however.
