There is no screen tearing. That is quite noticeable.
Core Xlib is entirely ignorant of vsync or anything relating to completed frames. It's an immediate mode rendering model in that everything you draw just gets thrown on-screen by the display server whenever.
Compositors were then bolted on w/redirect and damage extensions and basically randomly snapshot the client window contents before compositing a desktop frame, within that snapshot you can easily have tearing of half-drawn updates.
Further extensions and hacks have tried to fix this like Present and frame clocks from the gtk/gnome folks, but it's all opt-in by X clients and non-uniformly supported by compositing WMs or not at all in classical non-compositing WMs where the X server just draws things directly on-screen as the protocol requests arrive from clients.
You clearly don't know what you're talking about.
I tried using it over a decade ago on XOrg and it didn't seem to do anything useful...
[0] https://www.x.org/releases/X11R7.6/doc/libXext/dbelib.html
Edit:
It's definitely there in the Xorg xserver [1]. My memory is fuzzy as it was a long time ago but I distinctly remember wasting a day trying to use this extension and becoming frustrated with its ineffectiveness. Maybe it was just for lack of any vsync mechanism to schedule the swap?
[1] https://gitlab.freedesktop.org/xorg/xserver/-/tree/master/db...