Likewise.
It took me weeks to figure this out when I learned GObject/GTK+ back in the early 2000s. I ended up writing my own tutorial on the subject due to the existing documentation being so utterly lacking (https://gitlab.com/rleigh/ogcalc is its current home). I later ported all of my GObject-C code to C++; GObject has few redeeming qualities. It's a good example of "just because you can, doesn't mean you should". Yes, you can do OO in C; no, it's not a good idea. It's the wrong tool for the job, and you should use a more appropriate tools.
Manually constructing vtables, manually casting all type information away, manually propagating exceptions and creating closures etc. It doesn't take long to realise that this is all pointless make-work. Just use C++. It has classes, inheritance, exceptions and proper type safety, all built in. What takes several hours with GObject-C takes just a few minutes with C++, and... there are zero bugs. With GObject-C, all that hand-crafting of vtables and other fiddly details are a source of subtle bugs; the compiler won't pick up on a lot of stuff you can get wrong while the C++ compiler does it all for you. This is something which becomes increasingly bad when you try to refactor--it may have been correct and then be subtly incorrect, and you won't realise. When I ported all this to C++, it uncovered a few nasty and obscure bugs which had been hidden for years.
All this adds up to why many GTK+ projects lack manpower. Writing, maintaining and extending these codebases are a Sisyphean task. Unfortunately, the "C at all costs for all situations" mentality driving much of this (and I was guilty of such an attitude before I discovered that C was not the be-all and end-all of languages) prevents them being moved to more maintainable languages despite it being pretty straightforward to do so (I've done it for several codebases).
Back in the mid-2000s I was employed to write a commercial application using GTK+; I used GTKmm and the other C++ bindings. Even then, it was an exercise in pain; bugs galore at all levels and poor or nonexistent documentation; there's a reason lots of developers were and are abandoning it for Qt, and the documentation and quality of implementation are key factors in that. It's unfortunate because it didn't have to be that way. But in reality, using GTK+ doesn't make economic sense--it takes longer to produce something which is of inferior quality and harder to maintain, so it's both more expensive in developer time, and it's a poorer product for the end user.
While it's now years since I used it seriously, I look at the current dropping of piles of functionality and APIs which have been around for two decades, and I wonder if they have even the slightest concern for the two decades of third-party code using this stuff. It's rhetorical; they clearly don't. Sad that hacking on the toolkit for its own sake has a much higher priority than using it to develop actual applications, but that's what it is.