When you move a window in X so that it no longer covers up another, it will generate expose events in the uncovered windows, forcing a redraw. This program (client) responsible for that window will then issue drawing commands to update the window contents.
When you are using an off-screen buffer, this is no longer required; the entire window contents are stored, so there is no need to redraw it after an expose event. This could make network transparency very slow, however, since it means that a lot of data has to be moved between the client and server for a window update; the client will generate a new pixmap for the image, and this needs to be transmitted to the server.
The solution is the DAMAGE extension, which identifies regions of the original window image that have been damaged. This makes a number of things more efficient. First, it means that only updated pixels need to be sent over the network (if you are using a remote display). Second, it allows smaller screen updates, reducing the amount of GPU power and bandwidth required when moving windows around.
This can be used in combination with the old expose events to allow X to run with the same sort of memory footprint it used to have. The off-screen versions of windows do not need to have their entire picture stored; they can only store the visible parts, and have the newly exposed parts generated by expose events, pushed to the X server by damage notifications, and then composited by a compositing manager.
This provides the same kind of low overhead as the original X design, while allowing all eye candy that the more modern approach permits. Of course, if you are supporting translucent windows, you need a bit more memory, since you need to keep a copy of the windows underneath the translucent ones.
The DAMAGE extension is often lumped together with XFixes. This is a simple extension that tidies up a lot of loose ends in the protocol. One of the early extensions to X was the shaped window extension, used in the xeyes example application, which allows windows to be irregular shapes. XFixes, among other things, adds support for manipulating these clip regions as an abstract type, so only an object index needs to be transmitted between the client and server.