My understanding is OpenGL ES is intentionally designed to be a subset of OpenGL so mobile devices can be simpler and therefore cheaper. It shouldn't be surprising mobile hardware and software is more limited. If deleting 80% of the platform features made your iPhone $50 cheaper and last another hour on battery, surely that's worth it?
Also, I believe the reason glVertex was removed is because it is a very inefficient way to draw. It wastes a lot of CPU time in "jump in to glVertex function, do a tiny amount of work, jump out of function, jump in to glVertex function, do a tiny amount of work...". It's to the extent that glDrawArrays is always faster. Take a buffer, fill it with data as fast as memory can transfer it, then a single function call to send all the data in one go, resulting in negligable overhead. Interesting anecdote: at least in my work in 2D games, modern GPUs are so fast they can render a quad faster than you can write its vertices to a vertex buffer on the CPU. So performance is limited by the CPU overhead! So this really makes a huge difference to the performance of some applications. And on mobile performance is usually more of an issue. So by removing the old functions, you're forced to do it in a more efficient way which may boost your framerate. Not so bad, huh? Unless, of course, you write a compatibility layer on top, which will reverse the performance gains.
Another reason there isn't a compatibility layer is it isn't OpenGL's job: it's supposed to be a super thin layer on the hardware so you can interface to the capabilities of the hardware as efficiently as possible. I also expect writing a compatibility layer that is standards-compliant in the general case is extremely difficult - check out all the effort that went in to ANGLE, for example.
So I think it's just a misunderstanding of the purpose and design of the tools. In future, I guess porting from OpenGL ES to desktop OpenGL would be a lot easier. 0.02
Part of the story here is that OpenGL ES isn't a new version of OpenGL, it's a different API for different platforms. It's nice if you can take old code and make it run on a mobile device easily but overall that's probably a small consideration compared to having an clean API that performs well.
If we want to focus on immediate mode specifically, it arguably shouldn't be used even in regular old OpenGL. It's slower and results in overly verbose code. Most people seem to use immediate mode because that's what most of the tutorial examples use.
Maybe one way to tackle the switch from immediate mode -> vertex arrays (and maybe quads -> triangles) is just to make some macros that take old code blocks and generate new ones.
Are you sure it's fair to call it a different API? OpenGL ES is officially described as "well-defined subsets of desktop OpenGL" [1], which would suggest it has a great deal in common with desktop OpenGL.
Also, I believe the reason glVertex was removed is because it is a very inefficient way to draw. It wastes a lot of CPU time in "jump in to glVertex function, do a tiny amount of work, jump out of function, jump in to glVertex function, do a tiny amount of work...". It's to the extent that glDrawArrays is always faster. Take a buffer, fill it with data as fast as memory can transfer it, then a single function call to send all the data in one go, resulting in negligable overhead. Interesting anecdote: at least in my work in 2D games, modern GPUs are so fast they can render a quad faster than you can write its vertices to a vertex buffer on the CPU. So performance is limited by the CPU overhead! So this really makes a huge difference to the performance of some applications. And on mobile performance is usually more of an issue. So by removing the old functions, you're forced to do it in a more efficient way which may boost your framerate. Not so bad, huh? Unless, of course, you write a compatibility layer on top, which will reverse the performance gains.
Another reason there isn't a compatibility layer is it isn't OpenGL's job: it's supposed to be a super thin layer on the hardware so you can interface to the capabilities of the hardware as efficiently as possible. I also expect writing a compatibility layer that is standards-compliant in the general case is extremely difficult - check out all the effort that went in to ANGLE, for example.
So I think it's just a misunderstanding of the purpose and design of the tools. In future, I guess porting from OpenGL ES to desktop OpenGL would be a lot easier. 0.02