Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.
It IS C++ though. All of the moc keywords are just macros (that the moc happens to interpret otherwise). signal: is just `#define signal public` and so on. You could compile annotated code without moc without issues.
Signal/slot connections are also compile-time type checked if you use the Qt 5 function pointer syntax: https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html
I won't comment on the rest of what you say, as I don't really know enough about it.
Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.
If you're already developing in Qt, what do you think the probability of that is?
Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.