Maybe I missed it, but he did not seem to go into detail as to how the pixel was plotted. If the pixel was placed in a buffer, and then a texture was locked and the pixel was transfered, this would obviously induce significant overhead on its own (any time you need to communicate between CPU/GPU memory induces a huge lag, in shorter words)...although Carmack knows this better than anyone else.
Also, the actual pressing of the button could use more clarification. When did measurement start? On the button down signal? On the button up signal? As soon as the finger touches the button?
Oops I did miss that. I would argue that a clear is actually not the fastest method -- it would be faster to keep two buffers of different colors (pre rendered) and swap them on key press...although the difference should be pretty trivial ;)
You're right, clear can sometimes be quite slow on some hardware. Fast clears tend to only be limited to all 0s or all 1s and only full screen. In the worst case, the hardware has no support at all and has to setup and rasterise a full-screen quad and send that down the pipeline.
But the delay involved in rendering to the buffer is part of the delay under test. We are not trying to get the lowest latency possible with the hardware, we are trying to get the lowest latency that a game could conceivable achieve.
Also, the actual pressing of the button could use more clarification. When did measurement start? On the button down signal? On the button up signal? As soon as the finger touches the button?