> vsync only prevents partial renderers, not full renders, so disabling it does not remove latency in most cases,
V-Sync will, as the name implies, wait until the partial draw finishes. This "wait" is what is adding the latency.
> the idea that compositing is somehow slower is also very misleading... how exactly is a stacked renderer faster?
Yes, compositing is slower because when an application wants to draw its window needs to send the image to the compositor (or acquire the handle to the backing texture for the window that the compositor uses or whatever, that is implementation details) and then the compositor will at some point later draw it together will all the other windows (almost all compositors are V-Synced, meaning that you will see at most 60Hz updates - or whatever refresh rate your monitor is running at). This adds a very noticeable delay between the program needing to update itself and the update being visible to the user.
On the other hand, without a compositor and assuming a window system based on clipping regions (like X11 and Windows without DWM) with direct to frontbuffer drawing, the application will ask the window system to prepare for drawing in the window (which usually means the window system will setup the clipping to be inside the window's visible area), then perform the drawing directly on the framebuffer and notify the window system that it is done (so that the clipping stuff can go away). Notice how nothing here waits on anything else, like v-sync (or any other interval) and how this totally ignores other windows - each window draws itself immediately when needed instead of having to orchestrate an update for all windows on the screen.
Of course with the latter approach you do get tearing since you can have windows drawing themselves during a monitor refresh, but if that is a problem or not is up to the user. Personally i never care about tearing to the point that i barely notice it, yet i immediately notice any sort of V-Sync or compositor induced lag so i always try to avoid these.