There's more to it than FlightGear merely having to support/use OpenGL (exclusively) - see the wiki pointers for details.
In general, FlightGear is designed to be a desktop application with certain interfacing peripherals available - and as a matter of fact, even just when using FlightGear on a netbook (or tablet PC) you will encounter tons of restrictions that are unrelated to FlightGear not (yet) using/supporting OpenGL ES.
Regarding OpenGL ES in particular, there still is tons of hard-coded legacy code using raw fixed-function code that isn't easily "ported", and where even just updating that code to use OSG would be a huge step forward - that is one of the primary reasons why the Canvas system was originally conceived to be used for helping unify the 2D rendering back-end in FlightGear, so that all 2D rendering related components in FlightGear go through a single subsystem that can also serve as the encapsulation point, i.e. to help re-implement/port certain functionality without having to touch tons of components:
http://wiki.flightgear.org/Unifying_the ... via_canvasThat is why anything involving OpenGL ES (or targeting mobile platforms in general, e.g. gaming consoles) would definitely benefit from seeing 2D components like the 2D panels code, HUDs and the GUI re-implemented on top of a technology stack that can easily be re-targeted.
The other problem people would face sooner or later is the highly monolithic architecture of FlightGear as a whole, especially the initialization sequence and the main loop are still too static to easily scale for different kinds of mobile hardware (tablet PCs, gaming consoles, mobile phones).
It is true that mobile phones these days are much more powerful than the computers were in the 90s, back when much of FlightGear was prototyped and implemented - but it is also important to keep in mind that the primary use-case comes with a bunch of more or less implicit assumptions (screen estate, color depth, hardware acceleration, RAM etc).
Personally, I have come to the conclusion that the FOA folks were posting face screenshots, i.e. images that were photoshopped or taken via some kind of emulator.
Because there really are quite a few roadblocks, and that applies even to folks intimately familiar with FG/SG internals.
If anybody was really serious about trying this, the first step would be making the FlightGear boot sequence better configurable, i.e. more modular - so that only a subset of the FlightGear subsystems would be used, in conjunction with a place without any scenery (think ufo/ocean), and then take it from there.
Sooner or later, custom built scenery may also come into play. So, in general, this is far from trivial and would take quite a bit of orchestrated work, most of which is unrelated to OpenGL ES - and even if people were specifically interested in porting rendering related aspects of FlightGear, there would be tons of hard-coded stuff, as well as tons of effects/shaders that won't simply work "as is".
Compared to that, cross-compiling FlightGear and all it dependencies is the "easy" part - even just making FlightGear work in "console mode" (think headless) would require quite a bit of re-architecting, even if that only means dumping the equivalent of fgfs --help --verbose to the console or running the mongoose httpd.
Thus, I certainly don't mean to discourage anybody interested in exploring, but I would also suggest to tread carefully and set your expectations accordingly, i.e. this would even be a massive undertaking for someone with a 10+ year track record of developing C++/OSG software for a living and contributing to FlightGear for years.