Here's my take on it:
It may not be to redraw the frame when time exceeds 33ms. After all, the card can resend it after that time if it has no new frame, and quite possibly does.
(They say the card polls (source of current 1ms overhead) the module to know if it is still drawing a frame before trying to upload a new frame, even though one would think the card should know this very well: when the screen is drawing, it's because the card is uploading, or a tiny delay later; or it's because 33ms have passed and the screen is refreshing itself from onboard memory without the card knowing? Then the card could use a parallel timer to guess this).
Anyway, my take on memory:
The max rate is 144Hz, 7ms. Also, the link upload time is also 7ms (even when not reaching the full rate btw, which is good for lag).
Thing is, possibly they chosed to refresh the panel way faster (top-down) than the speed at which the data arrives, after receiving the image.
That's why you need memory to store what's coming from the link, and spit it later. Hence the buffering.
This faster update rate is good, because it means the changing of the whole screen is more instantaneous (unlike a crt where the image gets redrawn again and again without pausing inbetween, and different parts of picture have different lag).
This also probably means that pixels decay more simultaneously thus homogeneously and that maybe less complex y-dependent overdrive algo are needed if any. Oh! Also, think about multipass for these algos...Buffer needed to read twice. Or overdrive? Buffer needed for the last frame.
This faster refresh time, at last, is simply a requirement for crosstalk-free 3D / lightboost / ulmb.
So the time for all pixels being refreshed must be an order less than the refresh rate, lets say 1 or 2ms out of 7.
So you need to spit pixel data way faster than they arrived.
Faster than 144Hz 1080p (think it's 1440p or 4k ready)...3 or 7x faster. I did the math : 4.18GB/s for mere FHD and 2ms.
See, you need a bit of bandwidth. Oh! and this is for single pass.
Also, if they're smart, they can start slapping top pixels before bottom data has come, in a way both things finish simultaneously, like a youtube buffered video that plays when the beginning has arrived, and catches the download buffer right at the end perfectly. This saves lag (Mark here suggested this some time ago) (if multipass, you only gain on the last pass however).
As a side note, Carmack talked about non-topdown refreshes, maybe random or grid like. This had also crossed my mind. Visual results could be smoother. Another case where buffering the frame would be needed (though you could not start in advance in this case, you may want the last pixel early on
...Though if the pattern is algorithmic the card could send the frame in the correct format ie in the order the pixels are refreshed...Z order and Morton codes come to mind...After all that's precisely how memory is layed out in modern gpus framebuffers! So in fact, heh, it may actually avoid the linearization that probably takes place before the stuff goes on the wire).
[On second thought, I'm not sure it would be better that way, for this reason : granted, you sure lose the non-isotropous curtain effect of top-down refresh, but on the other hand, you lose locality coherence, ie locally similar pixel decay times, and that seems bad]