When I see "C/C++" referred to as if it identified a single language, it warns me that someone is about to write something foolish, or worse. That expectation was fulfilled here (albeit through no fault of Michael's.)
To say, "C/C++", makes sense in exactly one context: when identifying languages that can call into a library without a wrapper layer. Then it is a statement about the library and its interface, not about the languages or their properties.
The ability of UI framework coders to make any supercomputer feel like an HP-41 is legendary. Machines are a thousand times faster than in the '80s, yet GUI programs are as slow as ever, achieving very little more useful work, and often less. The problem to be solved is not to discover some magical language to consume even more overhead. It's to deliver to coders the existing power of existing machines in a way that allows that power to be applied to benefit the user. The problem was identically the same ten years ago. The slow progress is a disgrace.
Qt and GTK displacing other frameworks is progress only in the sense of consolidation: fewer coders are obliged to use the even-worse ones. Both still define their own universe of data structures that must be translated to and from native structures and wire protocols. Both (but GTK more than Qt) fail to take advantage of advances in programming language design since 1983. These failings leak into code that uses frameworks: Mozilla code, while nominally C++, infamously shies from all of the language's facilities that post-date 1990.
Modern language facilities embodied in standard C++ enable writing libraries that are more expressive than is usually achieved in a specialized language, yet without the overhead of another abstraction layer.
There is one shining example of progress, of user interface design exposing the power of modern hardware to users: twitch games. How sad that whenever they must do what another programs does, they fall back to doing it the same way, with all progress forgotten.