Qt is more than just a UI toolkit - it provides cross-platform windowing, networking, input, sound, fonts etc, all in a single library. So that's all the stuff useful for games, and at least as good as what you get in libraries like SDL. Qt can certainly be used for games in this sense. It is also fine for mobile, indeed, that's what Nokia used it for, to provide the primary API for the popular Symbian platform (I've used Qt for Symbian, Android, Windows and Linux). That Qt manages the main loop shouldn't be a problem - indeed, there are arguments in favour of this, for example it means the API/OS can manage better for battery life, rather than having to trust the programmer to get that right, which is important for mobile use. Why do you need control of the main loop?
It is incorrect to say that Qt wasn't built with games in mind, when it does have plenty of classes clearly geared towards that purpose. Whether it's the best API or not for games is another matter of course, but it's not that it was never intended for games.
So the problem isn't whether Qt can be used for games, but whether you can take advantage of the UI within the OpenGL window. I'm not sure if any UI designed for "OS friendly" UIs will work as well as the UIs that are designed to work with 3D engines - but on the flip side, you've got the cost that the latter don't tend to be as good in terms of the UI offered (which often isn't a problem for most games). This isn't a flaw with Qt, but something that no standard "OS friendly" API seems to offer.
Indeed, the blog post notes "So the real overhead of using Qt is only ~1ms per frame. That’s reasonable." He also notes that SDL would be no better - Qt still provides all the benefits of cross-platform windowing, network, input, fonts and so on, without having to need all the add-ons that SDL needs. Yet people still happily use and recommend SDL for games. The bottom line is that there doesn't seem to be a single API that can be used for non-game "OS friendly" application UIs, as well as being good for games (or is there?) - and the OP may well be better off with an API that is targetted towards in-game rendering.
(Another approach is to arrange your UI so that the UI surrounds the main 3D window, rather than having to be overlayed. For some kinds of games, this is fine - e.g., role-playing games, adventure; and anything you need to overlay can be left to more simple elements that you can roll your own. But if this isn't suitable, I'm not sure if any standard OS toolkit will be useful.)
If you choose not to use Qt for the UI, what are you going to use for all the other things you need (windowing, input, etc)? Qt is still a viable choice there
Qt is open source, and is not dependent on Nokia's future direction.
Qt 5 is bringing in a new UI system that should be better designed for GPU rendering, but I wouldn't hold my breath, especially since Nokia's gone Microsoft now.