> My thinking was why require an intermediate processing step of the moc, if the core c++ is capable enough.

Sadly it is not. C++ does not provide reflection - not without macros duplicating all your function names. GTK+ does not provide reflection. For instance with Qt you can just define a C++ object and directly access its properties & methods from Javascript, which is extremely useful if you want to add a scripting layer to an existing software.

You can also iterate over all the properties of an object to create UIs automatically.

> Also using the moc is a bit similar to using complex preprocessor-macr-ridden c code, which to me is an antipattern.

We sort of agree. gobject is a "kill it with fire" kind of mess, moc is not exactly the pinnacle of elegance either (but does more than glib gives you and somehow manages to be less weird than glib's macro jungle). The basic fact is that moc works around C++ not being able to provide this kind of functionality; so either you take some inconvenience (gtk, verdigris) or use an external tool (moc). moc doesn't usually give any trouble beyond being somewhat slow, so that seems like an acceptable deal for almost any situations you might consider using Qt in.

Gtk uses GLib which basically re-invent object oriented programming with "complex preprocessor-macr-ridden c code" boilerplate. I find moc approach much superior to that as it just help the programmer concentrate on what to program without having to manually write all the error-prone boilerplate. Qt makes UI programming in C++ easier, nothing wrong that.