Plus, you can support a much larger range of hardware with a true 2D renderer that targets specific 2D graphics APIs, than with a cutting-edge 3D engine hacked to look 2D.
There used to be a time when we had accelerated 2D graphics cards, even with support e.g. GDI, and then the 3D graphics accelerator was an additional card.
So there was a transition period when GPUs were still 2D accelerators that could do some 3D on the side.
Then graphics cards got the ability to do matrix operations in hardware, this was still mostly 2D with 3D super powers.
However then shaders came into the picture, as consumer hardware finally became cheap enough to adopt capabilities of graphics workstations hardware.
First only Assembly language for GPUs, but by the time DirectX 8 and OpenGL 2.0 became widespread, we got C like shading languages.
GL ES 2.0 is basically OpenGL 2.0 only with shaders and hardware transform and lighting removed.
If you want to make best use of the GPU there is no way around writing shaders, regardless of it being 2D or 3D graphics engine.
In fact you want to code most of the typical 2D effects as shaders running directly on the GPU.
And so even if I was careful to write shaders that efficiently operate in 2D space, those efficiencies would be trumped by the hardware converting it all to 3D space anyway?
I guess my intuition was that if you have a full 3D shader setup, eg the Unity renderer, that you add a layer of new shaders on top of to give a friendlier 2D API, that's going to be slower than just writing the 2D API on its own.
Graphics cards haven't had 2D acceleration for decades so you're always using the 3D features.
Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.