> Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?

To what benefit?

OpenGL ES is basically OpenGL minus all of the bits you really really should have stopped using over a decade ago. Originally all of that crap was culled out because it was only realistic to write new software for such resource constrained devices anyways, so why burden driver authors and hardware with the need to support crap that should never be used anyways?

Now that mobile device CPU/GPUs are powerful enough to start being appealing as targets for porting OpenGL-based applications, I think the proper response is less "great, slather back on all of the deprecated legacy cruft from the desktop version of OpenGL" and more "for the love of god update your rendering pipeline to reflect the last 15 years of progress".

Afaik OpenGL ES 2.0 is only a subset of OpenGL 2.0, and doesn't have anything from latter versions (3.x and 4.x). Fixed-function pipeline was removed in OpenGL 3.1 (core). See eg OSX implementation of OpenGL.

So OpenGL ES is not OpenGL minus legacy bits. It was that back in the day, but today it is far smaller subset. Implementing OpenGL > 3.0 would not require implementing fixed-function pipeline, and would benefit programmers using the latest and greatest features.

I thought the issue with immediate mode which prevented its inclusion (in ES) was that immediate mode is very inefficient for the CPU, resulting in increased battery drain on smartphones and tablets.

All rendering is in some capacity incremental. Sometimes you keep that (incrementally constructed) list of vertices around, of course.

If you look at the old immediate mode API, fundamentally, you're just passing in some floats that it copies into a buffer. This is not an expensive thing to do. It's not free, sure, but CPUs aren't bad at it. It's just some overhead compared to if you were to hand an entire buffer (in a known format) full of floats to the GPU at once. Some extra function calls, etc. If your app is only drawing a few thousand vertices, the overhead difference here is trivial... and if your app is drawing a million vertices, you won't be using immediate mode anyway.

Modern GPUs have to put the vertices in vram before they can render them.

That means immediate mode emulation is effectively this

    everyframe:
      a) copy all vertices from user code to some cpu buffer
      b) at draw time, copy cpu buffer to vram
      c) ask GPU to draw

steps A and B are very expensive CPU wise as well as waste memory.

vs OpenGL ES 2.0

    init time:
       put vertices in vram

    everyframe:
       ask GPU to draw