The actual good thing about Wayland is that it simplifies things. While the bad thing is that it needs some kind of extensions for even the basic things a desktop needs, and that (AFAIK) freeGNOMEdesktop is in charge now.
For GLX/DRI clients where there's an actual concept of swapping buffers w/vsync, sure, but for classical X clients this is not true.
X got extensions for double buffering at one point, but practically nobody uses them.
There is no concept of a "completed frame ready for presentation" in core X, there's no way to really fix this without ceasing to be X (hello, Wayland). X compositors literally just drain event queues of X requests and throw shit on-screen when the event loop gets around to it. If that presents a partially updated window, so be it. GTK+/GNOME folks added "frame clocks" to try work around it, but not everything is a modern-ish GTK+ app, nor do all compositors implement it.
If there's anything Wayland fixes that really required such an upheaval to fix, it's flicker/tear-free compositing.
GNOME3 had(has?) many a timing problems.
In X, there isn't really a concept of what a completion boundary is. The client asks stuff to be drawn, the display server gets around to it when it gets around to it, and makes the changes visible willy-nilly, eventually becoming consistent with the client state.
If you look at the source for xcompmgr, the event loop is pretty simple and clearly schedules repainting the root window with all newly received damage updates whenever its X socket is drained of new events [0]. This is a pretty arbitrary boundary to perform redrawing on; process scheduling, socket buffer sizes/limits, it's not well controlled at all. The way this is done it will make visible whatever damage events managed to get into this timeslice. If that results in only part of a window being updated, with the rest of the damage part of that "frame" arriving in the next timeslice, POOF, there's a tear.
[0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/mast...
(AFAIK random clients should not really be using this though, the intent is for it to get used internally by the GL/Vulkan implementation)