In my own game I use a combination of UIKit and Cocos2D (which is OpenGL ES based, for those not familiar with it).
The first iteration of my game used UIKit for menus, and then a game screen that was Cocos2D based. The game screen had buttons on it, as well as dialog messages that would pop up. These were all done in Cocos2D.
Over time, I have gradually replaced much of my Cocos2D code with UIKit, so that the game play screen is about 2/3 Cocos2D and 1/3 UIKit.
I have learned to love and use both frameworks for different reasons.
This has several advantages:
1) It's easier to have a consistent UI throughout the app. I was having to write code that would make my shiny UIKit buttons look just like my shiny Cocos2D buttons. Now they're all UIKit.
2) The UIKit API is stable. The best thing and worst thing about Cocos2D is that it is changing (improving!) so fast that I found myself constantly updating my code to support new features and API changes. Now the amount of code that gets affected by those changes is a lot smaller.
3) I have seen no performance loss by doing it this way. There may even be some memory gain because UIKit is pretty efficient with its use of resources when memory gets tight.
4) Development on things like pop-up messages and dialogs is a lot faster, because I can do those in Interface Builder. I don't need to think about how to lay out the dialog screens in code.
5) I don't have to reinvent the wheel on basics like buttons and tables.
After developing this way, here's my rule of thumb:
1) Use UIKit for everything that doesn't require OpenGL. Menus, messages, buttons, tables, etc. Core Animation does a good job on 80% of what I need.
2) If I find myself writing something that I have seen in UIKit, stop and try to think how I can pull it out of the OpenGL view.
3) Certain things like complex movement, particle effects, etc. are perfect fit for OpenGL/Cocos2D, so that's where I put that effort.