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.
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.
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.
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.
Thankfully having a *nix background helped Sun getting Java design regarding UTF just right.
Qt, as most frameworks, simply has the ability to get you stuck between a rock and a hard place. It's all a bit of a gamble of course. Similar to writing plug-ins for specific programs or apps targetet at app stores for a living. Someone can just decide to kick you out for no reason. I'm sure Qt doesn't intend to do that, they probably just want to do right by that almost-all-programs group. When you're that popular, ANY decision will hurt a lot of people.
What I'm trying to say is that I wish there was more of an effort in the programming community to avoid these asymmetric relationships. We already make a huge commitment by deciding what programming language to use, which often already comes with a built-in framework or standard library, a package manager and maybe even an IDE. For example, in the .NET world you have to constantly keep up with Microsoft's latest ideas on how to complicate the ecosystem by introducing yet another thing that is supposed to solve all problems at once, including those introduced by the previous attempts. If you're already in one abusive relationship, the last thing you want is two abusive relationships.
(And by "use" I mean use directly, not through some framework-abstracting metaframework you've written yourself - I think it's very obvious that's going to be a disaster. The whole point of a framework is to abstract over different APIs, so if you have to abstract on top of them then they serve no purpose. It brings to mind horror stories of hand-rolled database engines written on top of other database engines!)
I think your comment leaps directly from "if you can't use a framework directly then you're best off writing your own" (fair point) to "I don't like frameworks at all", without tackling the key bit in middle: how often is it possible to use a framework directly? The truth is, most applications can be built just fine with a framework like Qt. There is a gap between "hello world" and Krita that encompasses almost all practical programs.
Even in Krita's case, with all the pain they've encountered, they're still not seriously discussing abandoning Qt. They're even talking about maintaining their own patch set! Given how much experience they obviously have on the subject I think that shows there is value even in a framework that doesn't fully work for you. (I know that's an appeal to authority but I think there's some value in that argument.)
One compromise is to use a framework like Qt for all the boring bits of your program, like the dialog boxes and window decorations, then write your own wrapper for low-level APIs for the main display area if it needs it. I must admit I'm not sure how feasable this actually is given that something else in ultimately in control of the overall rending - maybe it isn't at all given that Krita doesn't do it.