Well this is what Qt does as far as my understanding goes. If you write Qt applications everything to be used in Qt must derive from QObject. I wouldn't call Qt bad because of that. Sure there's overhead with the vtables but that isn't a problem for everyone.
QObject is not a base class for everything like in those codebases GP probably thinks about. It's a base class for a very specific set of functionality that can be very roughly summarized as "the thing wants to participate in the signal-slot communication scheme". For example, QFile is a QObject because it has ready-to-read signals etc.
But there are also tons of classes in Qt that are not QObject, esp. all the value classes like QList or QPoint or QString.
If anything, the biggest sin of QObject might be its name. If it had been named QActor or something like that, people wouldn't mind that much.
Qt was first released when C++ had no more organizational features than Java, so it gets a free pass.
QObject is not Qt's greatest sin. That would be its lower-case macros: "slots" etc. There can be no excuse for that. Even C coders knew better, even back then.
