GTK and GIMP both suffer from the original decision by people who don't understand C++ to reinvent it in bare C except very poorly. It's what you get if you heard a rumor that vtables are bad somehow but don't realize that an array of function pointers is worse in every way.
Having worked with GObject extensively, including through PyGObject, I can say the experience is infinitely better than trying to make C++ interoperate with e.g. Python.
That makes sense since the implementation of things in GObject is basically the same as the internal architecture of Python. Since it's all just named properties and function pointers there's no chance that the compiler will rearrange it and break introspection. On the other hand there's also no chance that the compiler can optimize a GObject program, so you've traded good performance for an easier-to-use FFI for Python which might not be the trade I would have made. They've also traded away core developer productivity in order to make foreign language developers more productive, again a tradeoff I might not have made.
> Having worked with GObject extensively, including through PyGObject, I can say the experience is infinitely better than trying to make C++ interoperate with e.g. Python.
GObject is a ref-counted object system that is designed to make interop with all sorts of languages possible across FFI boundaries, including those with runtimes that include tracing GCs; such a thing is not built into C++.
If the GIMP authors would have used C++ in 1995 they would be stuck with a legacy codebase now that would be ridiculed because it's not "modern C++" - a term that has designated about 3 different programming styles during that time.
Even the Qt developers found that 1995 C++ was insufficient for a UI toolkit and augmented it with a custom "moc" pre-compiler and build tools.