Most users of course aren't affected in the least by the build process. Qt's build process is self-contained, but takes hours still. The end result is really the same for end users.
Sure, it's mostly the same for end users, but someone has to manage the insane build process. I remember gnome being dropped from Slackware because just packaging it was taking up too much of Pat V's time.
Having every widget toolkit re-implement every wheel is fairly tiresome. Why not use lower-level libraries like libxml that already work well, and most importantly, are C-based.
Mostly, portability. Qt-based programs are easy to port to even quite silly systems; porting libxml and all the other random libraries different parts of gnome is a lot of effort. Thus there's a fairly complete kde on e.g. windows, wheras only a handful of individual popular gnome programs have been ported.
Programming GTK+ in C++ is a joy (doesn't need moc either). GTK+ in Python is slick too, and actually manages to be fairly pythonic, unlike PyQt, which is really just C++ code in a python syntax.
Disagree, and I think the relative popularity backs me up. Have you read the post from rosegarden's author (wish I could find it) talking about moving from gtkmm to qt?
I don't think Gobject is a BS OO extension anymore than C++ is. Functionally and under the hood they are fairly equivalent.
That this is true is really the worst thing about the gnome approach. C++ and GObject are indeed basically the same thing (and vala makes this even clearer), but Gnome chose to reinvent the wheel, throwing away all our existing experience and tool support with C++.