When I started working on Krita 2003, it was already using Qt, of course, so I didn't have much of a choice -- if I wanted to work on Krita. But then, in a nice piece of circular reasoning, I choose to work on Krita because it was using Qt. Back then, I only knew Java, and Qt made C++ look like Java. One of the big problems I see in Qt is how the Qt developers are somehow ashamed of that heritage and want to make Qt steadily less Java-y and more Boosty or std-y.
Over the years, we've had a lot of pain, of course... But then again, a lot of fun, too, and without Qt we wouldn't have been able to create an application like Krita. Every alternative just is worse, much worse.
2003 was a long time ago: C++ has evolved, Java has stagnated and is falling out of fashion, and many traditional Qt peculiarities like nonstandard strings and collections or the custom preprocessor have gradually transitioned from idiosyncratic but justified to unreasonably antiquated and possibly unacceptable. I think making Qt as "Boosty" as possible is necessary for it to remain relevant.
Might be failing out of fashion, yet Microsoft just bought a Java company, is now an OpenJDK contributor and is one of tier 1 languages at Azure and Amazon SDKs.
Meanwhile, C++ lost its full stack status, the only mainstream OS that still offers C++ GUI tooling, is Windows, and none of MFC, ATL or UWP/WinUI APIs are "Boosty".
What keeps Qt relevant as the surviving C++ GUI framework not stuck in 90's tooling idioms are the paying customers, and those have quite clear ideas which compilers and ISO C++ versions they want to have Qt on.
It is not that they are ashamed, rather Trolltech made a series of decisions that make sense in the context that Qt was originally designed and the C++ compilers used by the demographic of paying customers, which does seat well with ISO C++ of all things crowd.
Meanwhile std::string still doesn't provide everything that compiler specific frameworks have been doing since mid-90's.
The problem with Qt not using std::string is when you (gasp!) want to integrate with non-Qt libraries that do use std::string. It has nothing to do with what std::string offers or does not offer compared to any other string implementation. std::string was the string implementation for C++ since before Qt began, and by not using it for their strings, they delivered a significant message about their desire to integrate easily with non-Qt libraries.
Qt not using std::string made a lot of sense when everyone though UTF-16 was the future. A 16 bit default string type was just what modern i18n friendly language or framework had to have. It’s only in the past several years with the rise of UTF-8 everywhere that it looks like a mistake.
But I looked at using Qt in 1999 and easily decided against it, in part for this reason. Those of us coming from a *nix background got the UTF-8 thing much earlier than people affected by the Microsoft worldview.
Over the years, we've had a lot of pain, of course... But then again, a lot of fun, too, and without Qt we wouldn't have been able to create an application like Krita. Every alternative just is worse, much worse.