It's not like there's this massive base of OpenGL code just waiting to be ported to embedded devices if there were just a few more API calls. Yes, there's glxgears, screensavers, and handful of open source games. You could probably get some old CAD programs to run on your Android. But if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter see…
Except he didn't port his code to OpenGL ES - he ported the missing API from OpenGL 1.3 to OpenGL ES. If it takes one developer three days to implement the missing API, then perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?
* It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process.
* It costs money to develop regression and validation tests.
* It costs money to test, including collecting all the different hardware it needs to be tested on.
* It costs money to fix bugs in it.
* It costs money to answer questions from developers about it.
* These costs are multiplied by every future version that will continue to support it.
* These costs are multiplied by the many vendors that will be required to implement it.
* Some of these costs are multiplied by every language that will support bindings to the API.
* It costs code space in embedded devices.
* It costs as much as a vendor wants to spend trying to make it perform as fast as possible.
* It costs conceptual complexity in developers' heads.
* It costs developers when they inadvertently do things the old inefficient way.
* It costs reputation when somebody compares benchmarks of your product using the old inefficient way against another vendor's product using the new recommended way.
* Requirements to continually support it at the same level of performance constrain your choices when developing new hardware.
* Sometimes it costs precious die space which could be better used for other things.
* The inefficiency sometimes increases power consumption and reduces battery life.
* Users are disappointed if every version of new hardware doesn't run the old inefficient code even faster than the previous version.
So if it doesn't have a real need to be there in ES 1.0 then, yes, it is actively damaging and should be thrown out in the rewrite.