Before that time, we were using WxWidgets and had many issues, notably with Unicode and Windows support. WxWidget APIs and behaviors were changing too much between releases (even minor ones).
When we moved, we were in the early Qt 4.1/4.2 days, and most VLC developers were using Gnome and pushed a lot for Gtk. But one developer started the new UI in Qt, and I picked up the work. We had an important backlash from users, notably with some people in the community recoding an interface in Gtk...
Afterwards, QGtkStyle was introduced, and people could have a native look, even with Gtk environments.
Finally, Qt moved to a community project, to LGPL and Gtk went down the road with Gtk 3.x, breaking themes, Windows, OSX, and API/behaviors at every release (and removing features).
Those days, every cross-platform application are moving to Qt (subsurface, LXDE, wireshark, audacity).
It's funny that we made this decision, at that time, without knowing all that. I think we just got very lucky... :D
I.e. in Qt3 and previous versions, creating a parent-less widget resulted in a window frame being created. Why was that? If I am creating a button I do not want a window frame around it. I am going to insert the button to another widget later.
Thank God they fixed that in Qt4 and later versions.
But there is this massively annoying little bug where submenus close immediately when you hover another top menu item before reaching the submenu. This makes quickly navigating menus quite cumbersome. (Doesn't happen with native Windows interfaces.)
Does anybody know if the Qt devs are aware of this? Don't they think of it as an issue?
If so, then yes they are aware of it and treating it as critical.
Edit: Reading into this bug is so cool. This video was linked from it, fascinating stuff:
Gtk was a pain to develop with, sure, but only due to the awkwardness of GObject's attempts to build an OO system on top of C.
From a user perspective, I never saw the problems you're describing. Even having built Xfce out-of-tree all the time, I never recall having to do a full rebuild due to a Gtk update.
I've since moved on; it's a shame to hear what the OP is saying about 3.x, but 2.x most certainly didn't have these problems that you describe.
I don't recall the stability of the 2.0.x series, though: it's possible they didn't get things right and were still making breaking changes even though it was the stable series. I don't remember that being a problem, but I'll admit my memory of that period isn't perfect.
I do remember some app developers prematurely upgrading and releasing versions that depended on early development releases of 2.0 (and later, on the 2.1.x unstable series), which often did cause breakages. But that was really the app developer's fault for depending on versions that made no API/ABI guarantees.