The Gimp devs taking nine years to port from Gimp Toolkit 2 to Gimp Toolkit 3 kinda invalidates all claims about porting between Qt versions being too hard, doesn't it?
It's kind of important too because bugs in Gtk2 aren't getting fixed anymore. I ran into DBUS related issue with Gtk2 and ScrolledWindows in Ubuntu 20 and the dev response was basically "ew, gross, I'm not touching that". Fixing it required me to rewrite the app to use Gtk3 instead.
Devs wanted to do it all at once
Biggest fault of the Gtk/GNOME ecosystem these days is a small bunch of atrociously toxic people centering around RedHat shouting "Nobody besides me works on this, and that! So sit tightly, and shut up with your feedback!," while completely forgetting that it was them who scared off, and trolled out most normal people out of the GNOME community, including some of the best devs they had.
>If anything, we have to turn the GNOME community around and make this community a tolerant community, and a community of love. I have to say that I am surprised by how well the gnome-love mailing list has taken of, and surprised to see various newcomers to the platform actually writing code and becoming productive.
Also, that was quite a long time ago (some posts are from earlier than 2003) and most of those people involved in those threads don't appear to be associated with the project anymore. It certainly seems like they were able to work out some of their process issues in the last 17 years seeing as how the bonobo/orbit parts were dropped entirely.
Not to say UX designer are not important, but, IMHO, very good one are rare and stubborn one common place. Not that we devs are any better.
Not only that but as outlined in that article, GObject introspection allows easy integration with most popular dynamic languages (most importantly JS and Python) without the need for specific bindings.
GObject helps out with other languages like Rust and Lua.
That brought back some funky history.
In the days of yore, when Qt 4.5 roamed the lands and 4.7 did not exist yet, there was a set of Python bindings called PyQt. They were ... a bit clunky, but they worked. Perhaps more importantly, they were also a subject of cross-company political wrangling.
Nokia bought Qt back in mid-noughties and wanted to make the toolkit more easily accessible for mixed commercial use. Authors of PyQt didn't want to relicense to include LPGL as an option.[0] So PySide was born.
When the development of Qt5 got under way, the developers realised they could finally break many of the internals and eliminate a lot of nasty legacy baggage. The public API remained mostly the same, but low-level bindings, and pretty much anything that poked under the hood, could expect APIs to change, headers to go through contortions and so on.
Considering that the bindings for Qt5 are called PySide2, I can make an educated guess that it was in the end easier to rebuild the new bindings from scratch for 5 and onwards, rather than try to shoehorn the use of possibly conflicting low-level APIs between the two major versions. The name "PySide" was already known in developer circles as "LGPL friendly Python bindings", so holding on to the base name makes perfect sense.
I code cross-platform in C++ or Python primarily, so maybe that's why Qt is such a good fit. All the frequent version incompatibilities of Gtk3 just made me not really look into it any further.