Missing the point: you can write a blazingly fast android app in c++ with opengl; but it cant do anything useful because it can't use ui components, and will be stuck with sucky custom in-game ui components which, I think it's fair to say, are universally terrible (the QT port being the one exception to this).
If you can in _any way_ achieve a method of using the existing android ui components and making them faster, this is a massive win.
Actually the trend on both mobile platforms seems to be away from stock components to either heavily re-skinned components or completely bespoke components. Games in particular tend to go their own way on this, probably partly because they need to be x-platform.
Games (and often multimedia creation apps) have been rolling their own UI for a long time.
I think you still miss his point - games have been rolling their UIs out of necessity for a long time, in large part because in most OSes (mobile or otherwise) native UI widgets simply do not mix with a big real-time rendered DirectX/OpenGL surface.
So games have always been the fastest, most optimized performers on any platform.
This isn't about games though - this is about regular ol' apps, many of which are incredibly slow and could really use the 8x performance improvement that these folks have been able to achieve.
As a mobile dev myself, I don't think mobile platforms are moving away from Obj-C or Java. Sure, we have a lot of custom-built widgets to overcome shortcomings in what Google/Apple provides, but ultimately they're subject to the same performance limitations that plague the stock widgets. Nobody out there is digging into low-level OpenGL optimizations to write a custom navigation bar, for example.
Sure. Game devs don't build UIs in C++ and OpenGL because it's faster. It's because it's the lowest common denominator on the platforms they care about, which is why I was observing that it's funny that C++ is in a very pragmatic sense more portable than Java now.
Most devs use some kind of wrapper library like Cocos2d to take the pain out of raw OpenGL, of course, and they can usually get by with much simpler library of widgets than the OS itself has to provide.
If you can in _any way_ achieve a method of using the existing android ui components and making them faster, this is a massive win.