I agree that Qt is a nice framework to work with. Still, there are a number of issues I have with it:

1. It is written in C++, which is a really low level language. The fact alone that it is C++ will make every Qt programmer significantly less productive compared to Frameworks written in other languages. My main beef with C++ as a GUI development language is that it has next to no notion of automatic memory management, which makes the development process a lot more prone to errors. It is not introspective, which makes debugging a lot more difficult. Most of the other major GUI toolkits have some notion of automatic memory management and introspection.
2. Every cross-platform toolkit suffers from the problem that it only ever can implement the least common denominator of all supported platforms. That, and different UI guidelines on different platforms very much questions the desirability of cross-platform GUIs at a whole.
3. Qt is very much centered on coding up all your UI. Even though you can use QtDesigner to build some parts of your UI, it is seriously lacking in comparison to, say, (Cocoa/Obj-C) Interface Builder or the .Net tools.
4. Even though Qt does include a lot of low-level application functionality, it can not compare to having a framework hand-tailored for a certain platform. The native operating system libraries for both Windows and OSX are significantly more powerful than Qt's implementations. (Think audio frameworks, low level file system access etc.)

That said, I love using PyQt for rapid application prototyping or in-house applications. Using Python to do all the coding alleviates the concerns with C++ and actually makes Qt a very pleasant place.

I agree that Qt is a nice framework to work with. Still, there are a number of issues I have with it:

1. It is written in C++, which is a really low level language. The fact alone that it is C++ will make every Qt programmer significantly less productive compared to Frameworks written in other languages. My main beef with C++ as a GUI development language is that it has next to no notion of automatic memory management, which makes the development process a lot more prone to errors. It is not introspective, which makes debugging a lot more difficult. Most of the other major GUI toolkits have some notion of automatic memory management and introspection.
2. Every cross-platform toolkit suffers from the problem that it only ever can implement the least common denominator of all supported platforms. That, and different UI guidelines on different platforms very much questions the desirability of cross-platform GUIs at a whole.
3. Qt is very much centered on coding up all your UI. Even though you can use QtDesigner to build some parts of your UI, it is seriously lacking in comparison to, say, (Cocoa/Obj-C) Interface Builder or the .Net tools.
4. Even though Qt does include a lot of low-level application functionality, it can not compare to having a framework hand-tailored for a certain platform. The native operating system libraries for both Windows and OSX are significantly more powerful than Qt's implementations. (Think audio frameworks, low level file system access etc.)

That said, I love using PyQt for rapid application prototyping or in-house applications. Using Python to do all the coding alleviates the concerns with C++ and actually makes Qt a very pleasant place.

Edit, in response to some comments:

When I wrote about Qt being written in C++, I was not so much complaining about Qt itself, but more about the environment it lives in. It is true that Qt manages its own resources very well, but all your GUI-related-but-not-Qt code has to be written in C++, too. Even there, Qt provides many nice tools, but ultimately, you have to deal with C++ at that level. Qt makes C++ bearable, but it is still C++.

As for introspection, what I mean is this: The hardest cases to debug are when you have a pointer to some object that does not behave the way you think it should. With C++, your debugger might be able to look inside that object a bit (if it happens to have type information at thwt point), but even that does not always work. Take, on the other hand, Cocoa in the same situation. In Cocoa/Obj-C, you would be able to send messages ('call functions') to an object right within the debugger. You can change the objects state, you can query it for its attributes, you can ask it for its type and its function names... This can make debugging a lot more convenient. Qt/C++ has nothing even close to that.