I'll bite. Define "better" here.
Is it developer ergonomics? That's the only thing I can think of, and even then that's debatable.
Making a wrapper for Qt is not really any more complicated by Qt being written in (old-style) C++ than if it had been written in C. In fact, lots of languages do have Qt wrappers. As for Qt being object oriented… well, while that might indeed have been a problem for a language that is not… all your examples (rust, go, dart, D, ...) are, so that's hardly the problem there. Also, as far as the declarative and reactive goes: Qt does do that as well, and way better than any browser-lib-based webrendering engine (including mozilla's)
The real pain point with Qt is with its licensing at least since Qt was bought by Digia.
Second, it has QML, which is a declarative UI framework with great runtime performance.
If OSX, Windows, and the mobile stores carried a common framework developers could target it would become a defacto UI standard since you could finally develop a cross-platform app that used 'native widgets' (at least a library that might already be installed) for every given platform, and which could have an OS prompt that asks to install it from a trusted source if they don't happen to have it.
I’d love to see better cross-platform desktop apps. But I think the missing piece is for someone to write a good library that uses native widgets – not figuring out how to distribute that library.
For the record, I think Qt is reasonably good, but not native enough. On macOS, even QWidget often imitates native widgets (poorly) instead of using them; on top of that, QWidget as a whole has unfortunately been semi-deprecated, in favor of newer QML stuff that doesn’t even try to look native.
As for QWidget being semi-deprecated, this is not the case. They made some noises in that direction around the time Qt 5 was being developed but I think they thought better of it, so it's alive and well and still being developed.
- Text fields are not backed by native NSTextViews, so automatic substitutions, spell checking, and the options you usually have in the right-click/Edit menu are all missing.
- Pop-up menus (but not top-menu-bar menus) are also custom, and the appearance and animations are way off. And there are some discrepancies in behavior:
a. Suppose you right-click and hold (which opens the right-click menu in a mode where you select menu items by releasing instead of clicking), then release while over a menu item that's either disabled or a submenu. With native menus, the menu gets dismissed; with Qt menus, it stays open. Sounds incredibly minor, right? But it's something I grew to subconsciously rely on, over years of using macOS. When I started using a Qt app, I kept instinctively trying to dismiss menus that way and getting frustrated when they stayed open.
b. If the mouse cursor leaves the menu area, native menus stop highlighting any item, while Qt menus keep highlighting whichever item was last highlighted. In the press-and-hold mode, this makes it seem like releasing the button might choose that item; it actually dismisses the menu, same as with native menus, but it's confusing.
You are comparing apple and oranges when comparing the feature set of a small UI system made by 1 person-ish vs something like Qt benefiting from decades of experiences and hundreds of devs.