I'm pretty sure OpenGL ES 2.0 (pedantry: not at all the same standard as OpenGL 2.0) was a platform requirement for everything from Eclair (Android 2.0 -- the Nexus One) forward. I'm sure that factory-new Android 1.x devices still exist in the market somewhere, but you'd be very hard pressed to find one. Note that the original iPhone and 3G didn't do GLES2 either, so the platforms got the support at roughly the same time.
The bit about pixel-perfect art matters to some, I guess. PC game vendors have been doing resolution-independent games for decades now, so it's hardly a killer. But if you have to have it, then you're stuck with the iPhone (not even iOS, obviously, as you'd have to chuck iPad support).
And the rest is just saying that "OpenGL is hard". Yes: if you want to code to precisely the extension support and bug-for-bug quirks of one GPU (presumably the PVR SGX 5xx in your case), then it's easier to support just that phone. Duh. But that seems like bad practice to me. What if Apple goes with Mali or Tegra3 for the iPhone 5?
There are some new devices (I'm looking at a Huawei M835 running 2.1) that don't have 2.0 support.
As for "OpenGL is hard" - I think a major point here is that Apple has made it far less so. Because of their extreme curation of devices (re: only Apple produced devices), and the ease of software updates (well over 30% of phones are upgraded to the latest iOS version [1], with > 80% on a 5.x version [2]), iOS has continued to be a remarkable homogenous platform.
As far as Apple choosing a new graphics chip for the new device, it's certainly possible. With iOS, though, you can support a known list of devices and have 100% coverage rate. On Android you either have to whitelist phones (and therefore exclude users), or try to do feature detection at runtime to enable the correct codepaths.
It's deeper than "OpenGL is hard." Right out of the gate, you are hit with the one-two punch of different texture compression formats being supported on different devices combined with a maximum APK size on Google's store. The only standard Android texture format with compression is ETC which doesn't support alpha. So right at square one, if you want to use compressed textures for maximum performance and resolution, you have to release 3 separate APK's with a different supports-OpenGL-texture tag in each manifest. One for DXT, one for PVRTC, and one for ATC. Or dynamically download megabytes of textures after detecting which GPU you are running on.
That's a sharp contrast with iOS's unified, simple developer story: all PVRTC without any maximum app size.
That's not iOS's story, it's Imagination Technologies' story. The story from Apple will change the moment they ship a device on someone else's GPU. If this is something you expect to rely on, you're in the position of someone writing Altivec code in 2005.
But yes: texture compression formats and hardware support are a terrible, terrible mess. Happily I believe the early patents on S3TC are set to expire soon.
A minor addition: Android supports OpenGL ES 2.0 since Version 2.0, but JNI bindings to access the library from Java code are only available since Android 2.2 (API Level 8).
The bit about pixel-perfect art matters to some, I guess. PC game vendors have been doing resolution-independent games for decades now, so it's hardly a killer. But if you have to have it, then you're stuck with the iPhone (not even iOS, obviously, as you'd have to chuck iPad support).
And the rest is just saying that "OpenGL is hard". Yes: if you want to code to precisely the extension support and bug-for-bug quirks of one GPU (presumably the PVR SGX 5xx in your case), then it's easier to support just that phone. Duh. But that seems like bad practice to me. What if Apple goes with Mali or Tegra3 for the iPhone 5?