So what's with this design decision?
Not as helpful as it looks on first sight.
For one, it does need at least three chips for latching the data (8 Bit Data and 11 to 16 bit address) plus a considerable number to handle the access whenever there is time, plus a some muxes to switch the busses, as the CPU still needs the ability for read data from screen memory. Quite a lot of pins to solder (and pay for).
Second, the gain is rather meager. It's only a single (write) access that gets buffered. As soon as there is a second (before the screen memory can be accessed again), the CPU gets halted … as without. Equally important, the CPU gets also still put on hold for a read access.
To validate this it helps to take a look at (average) screen timing. Lets assume a system where the video part needs the whole RAM bandwidth during display (or at least so much that there can't be any CPU access in between). During a picture this is only true while a scan line is displayed. Lets stay with 1980s TV sized picture. Here a line is defined as 64 (63,6 for NTSC) µs. Thereof 12 (10.9) µs are used for synchronisation purpose and 52 (52,7) µs are for a potentially visible signal. Let's just assume the VDC uses all of that.
52 µs is quite some time in a CPU life – and especially more than enough to attempt to write more than one byte to screen memory. On a 1 MHz 6502 that equals up to 6–8 sequential writes in a tight copy loop. A 4 MHz Z80 can as well do up to 9 writes during that time (Let's for simplicity assume it tales 10µs per single meaningful write). That's about the maximum. And it'll of course overrun the single transaction buffer. To really use it some FIFO for address and data is needed. Increasing cost again.
Of course even a FIFO would only postpone the access into the gap between lines. Then again, a memory good enough for either of these CPUs will be able to squeeze a good 20 write access into the line retrace. So yes, such a FIFO could resolve it and give the CPU seemingly unhindered access. As noted, that's only true as there is no intermediate read access, which would halt the CPU again. So no bitblit please. Not to mention that there needs to be some priority logic to maybe let a waiting read slip in at the beginning of a line gap before the buffered writes are done, so the CPU only needs to wait for a minimum … err … no, bad idea, as it would possibly deliver old, already changed data, which has just not been committed by now. Drats.
The Whole Picture
A picture isn't just lines, but also frame structure. There are 286 (243) visible lines for a total of 18.3 (15.5) ms within a 20 (16.6) ms frame (50/60 Hz). With our model CPUs that allows for a maximum of ~170 (110) bytes written outside the visible part. In addition two writes per line can be done (*1), adding it up to 456 (353) accesses per frame or 22.8 (21.2) KiB/s (*2).
Adding a single access buffer to this would increase this by ~62 (68) percent to 37.1 (35.7) KiB/s. Sounds not bad. A 10 entry FIFO will even get it up to close to full speed (something like 100 KiB/s). Even better, isn't it? Except, this will break down quite hard if the job is not just a tight copy loop, but maybe some bitblitting with decisions and transformations in between.
So, What to do Instead?
As long as the timing requirement isn't too tight (as in 'already using the fastest RAM affordable'), it's better to avoid a collision at all by using RAM with a bandwidth of double what's needed for screen refresh (or CPU, whatever is higher), so the CPU can access it with no (or little) speed penalty. Something very common on 6502 systems, where RAM anyway has to be twice as fast as the CPU. Now there are no additional cost for perfect access.
On the backside, this requires RAMs always being double the speed, even when not needed (during retrace).
Only Partial Take Over
The C64s VIC shows an in between solution, by mostly acting when the CPU isn't accessing the RAM and only stoping it when it needs additional bandwidth.
Just Live With It
As seen in the whole picture calculation, while we are talking about a 60+ percent speed up in tight loops, it is in absolute numbers still a meager transfer rate. A lot of Hardware to gain a little.
Better Improve the Rest
Instead of spending a handful of TTLs on a little and often not reached gain, using the same amount of gates for a more capable VDC could be way more rewarding. Building a (very simple) DMA copy circuit can move like a 5 to 10-fold amount per time than the CPU can do (*3). Adding a full DMA controller to the system might cost even less. Then again, with a specific circuit additional benefits are possible – like bitblitting and so on.
Did any retrocomputing system buffer the write so as to let the CPU run at full speed whenever it's not reading from the framebuffer (which is practically always)?
Leaving the interleave/partial blocking systems apart, there are all machines using a 9918. It does buffer one transaction and a 3.5 MHz Z80 could access it (virtually) without being stopped (*4). Similar systems that used a second CPU for I/O had that advantage. Though, not many where made.
*1 – Thats one lovely part – and crucial to memorize: Any access done during a line will stop the CPU (in basic configuration), and release it one memory cycle after the end of the line. Giving the lock the whole 12 (10.9) µs for another interaction, which can be done in a tight loop, making the next write happen instantly and then putting the CPU on hold again. So as soon as the horizontal retrace is longer than one loop iteration plus one memory cycle, always two will fit – already creating parallel action for up to 2/6th of a line.
*2 – Here also lies one major reason why early computers had to use tile graphics and sprites (besides not enough RAM): not enough bandwidth. A CPU of that kind can not move even in a tight loop more than about ~2 KiB per frame – without being halted that is. Not enough to brute force an acceptable frame rate. Using tiles and sprites reduced the amount to (maybe) less than an 1/8th, making it possible again to sustain a good frame rate (still needing a good tile design :))
*3 – No, using a Z80 LDIR is not the same as DMA. It takes 21 cycles to move a byte. With two cycles per memory access, DMA can do the same in merely 4 cycles.
*4 – Calculation is a bit complex here, as for one the 9918 has a basic access time of 2 µs plus 0–6 µs wait, depending on internal action (frame or line) and within a line on what graphics mode is used. With a Z80 and LDIR as (a fast) use case, this comes down to a maximum effective CPU clock of 2–10 MHz depending on when the access happens. For all practical matters a 3.5 MHz Z80 can write to a 9918s screen memory virtually without being slowed down.