First you'd need to work out why someone would develop a desktop application rather than a browser-based application. Even once that's resolved it is not a given that you'd choose Qt.
Factors that might weigh in favour of developing a desktop application:
Some applications expect access to native platform features -- for example audio IO, or custom data acquisition, or access to native hardware capabilities, or last-20% performance. Although there are workarounds to access this kind of stuff from a Web UI, sometimes it is considered easier to just write everything in one platform-native language. Obviously over time some of these technologies come to the web (e.g. Web audio, WASM) but some people prefer to program a real machine, not a W3C specified VM.
There is a perception that web or Atom applications use more resources than a well tuned C++ desktop application. If your application is already resource intensive then putting a resource intensive web UI on it doesn't necessarily make sense.
Personally I have the perception that web technologies are too volatile to take a long term bet on. I don't consider that rewriting my application every few years is a good use of my time. That said, the release churn on Qt is now way too high for my liking.
I wouldn't underestimate the "If all you have is a hammer everything looks like a nail" mindset -- if you're a C++ programmer, developing a desktop / Qt application might be more appealing than using web technologies. Of course it goes the other way too.
Once you've determined to make a desktop application, then you can ask why you would use Qt for cross-platform UI (note that there are other reasons to use Qt, such as for embedded UI).
No doubt your "insufficient for power users / sophisticated use cases" is sometimes applicable. But I think this is mostly related to "native desktop app" vs "browser-based" rather than Qt / not-Qt. There are many cross-platform desktop applications that choose not to use Qt.
So you really have to look at the problem Qt deals with. UI APIs on each platform are radically different: no matter how you approach it, cross-platform UI requires a portable UI architecture, and Qt provides this architecture off the shelf.
Qt also provides a whole lot of other frameworky stuff that you may or may not want or need. It's a one stop shop.
Some application developers want something close to native look-and-feel but want to outsource-cross platform UI (a kind-of write once, run everywhere, at least for the UI). In this sense Qt is one of the middle options in the "Native / cross-platform / web" continuum.
Factors that might weigh in favour of developing a desktop application:
Some applications expect access to native platform features -- for example audio IO, or custom data acquisition, or access to native hardware capabilities, or last-20% performance. Although there are workarounds to access this kind of stuff from a Web UI, sometimes it is considered easier to just write everything in one platform-native language. Obviously over time some of these technologies come to the web (e.g. Web audio, WASM) but some people prefer to program a real machine, not a W3C specified VM.
There is a perception that web or Atom applications use more resources than a well tuned C++ desktop application. If your application is already resource intensive then putting a resource intensive web UI on it doesn't necessarily make sense.
Personally I have the perception that web technologies are too volatile to take a long term bet on. I don't consider that rewriting my application every few years is a good use of my time. That said, the release churn on Qt is now way too high for my liking.
I wouldn't underestimate the "If all you have is a hammer everything looks like a nail" mindset -- if you're a C++ programmer, developing a desktop / Qt application might be more appealing than using web technologies. Of course it goes the other way too.
Once you've determined to make a desktop application, then you can ask why you would use Qt for cross-platform UI (note that there are other reasons to use Qt, such as for embedded UI).
No doubt your "insufficient for power users / sophisticated use cases" is sometimes applicable. But I think this is mostly related to "native desktop app" vs "browser-based" rather than Qt / not-Qt. There are many cross-platform desktop applications that choose not to use Qt.
So you really have to look at the problem Qt deals with. UI APIs on each platform are radically different: no matter how you approach it, cross-platform UI requires a portable UI architecture, and Qt provides this architecture off the shelf.
Qt also provides a whole lot of other frameworky stuff that you may or may not want or need. It's a one stop shop.
Some application developers want something close to native look-and-feel but want to outsource-cross platform UI (a kind-of write once, run everywhere, at least for the UI). In this sense Qt is one of the middle options in the "Native / cross-platform / web" continuum.