Unfortunately, all I have is my iPad 2 to test this right now (my iPad 1 test unit is sitting at home), and it has ridiculously fast fragment processing. It's being pegged at 60 FPS, with 1400 theoretical FPS in your logging.

However, I ran it through Instruments using the OpenGL ES Driver and Time Profiler instruments, along with the cool new OpenGL ES Analyzer (which comes with Xcode 4). This is what the results from the OpenGL ES Analyzer look like:

Looking at the Tiler Utilization statistic in the OpenGL ES driver shows the tiler barely being used at all, but the renderer having some use (again, only 5% on my iPad 2). This indicates that the suggestions to use VBOs and indices for your geometry probably won't do much for you.

The one that sticks out is the warning about redundant calls:

You keep binding the framebuffer and setting up the viewport every frame, which according to Time Profiler is accounting for 10% of the work load in your application. Commenting out the line

[(EAGLView *)self.view setFramebuffer];

near the beginning of your frame drawing caused the theoretical framerate to jump from 1400 FPS to 27000 FPS on my iPad 2 (as an aside, you should probably measure using milliseconds for your rendering).

Again, this is me running tests on the really powerful GPU in the iPad 2, but you should be able to repeat these similar steps on the original iPad or any other device to verify this performance bottleneck and potentially highlight others. I've found the new OpenGL ES Analyzer to be really handy in picking up shader-related performance issues.