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.
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.
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.