I'm not against generated code per-se. But in the case of signals/slots, we have had a robust, type-safe solution to replace the moc implementation as pure C++ compile-time-checked constructs which is superior to the moc-generated code. This is what libsigc++ and boost::signals both do, though they don't by default do anything with introspection--but you could add that on top. Qt5.0 gets us half way there with signal connection, and that's arguably the most important part. It would be nice if it could be taken all the way, though.
With a bit of thought, it's equally possible to do properties at compile/runtime as well, including introspection. For example, using templated property proxies and lambdas for the getters/setters. Again, completely type-safe compile-time checked etc. Example: GLib::PropertyProxy<> in GLibmm; though it's layered on top of the GObject property mechanism, it could be based on something else.
For me, the value added here is the compile-time checking, robustness, simplicity, and removal of the need for an additional code-generation step in the build. You now can't get any runtime signature mismatch failures unlike with moc. Also, when Qt is just one of many libraries being used, qmake is often not an option, particularly when Qt is just for an optional UI component in a larger project. Just like bjam isn't an option when using Boost, etc (mainly because it's incomprehensible!). And writing all the extra make rules to run moc is time-consuming and fragile when you have to do it by hand, so removing it when possible can be useful.
The other issue when integrating into a wider non-Qt project is that Qt-using code is no longer strictly C++: It's a Qt dialect which is processed into C++ at build time (I'm referring to the slots: syntax etc). And the non-standard containers can also be an issue; it would be preferable to use the C++ standard equivalents whenever possible (I know this has improved, but as someone who codes using plain Standard C++ with TR1/boost/C++11, using the standard forms by default is highly desirable). GTKmm/GLibmm manage to use standard C++ to a much greater extent, though Qt is certainly getting better, and I'm increasingly using Qt for newer projects as a result.