Text editing. I mostly work on a single line at a time. The chance of the tear ending up in that line is low. And even if it does, it lasts only for a single screen refresh cycle, so it's not a big deal.
And you're not limited to two images. As the frame rate increases, the number of images increases and the tear becomes less noticeable. Blur Busters explains:
Text editing is mostly about reading, not writing. Scrolling up and down code is actually one of the worst scenarios i can think of, where you absolutely don't want to have tear. Because even as the document is moving you are still reading it.
When touch typing, fingers work decoupled from the eyes anyway, unless you are waiting for the intellisense or copilot prompt, that is usually constrained by language servers anyway, not the framerate.
No, the monitor’s refresh rate is a hard limit on the minimal maximal-latency. It doesn’t mean that you are actually close to that minimum, or that it is the hard limit that is active, aka the bottleneck.
Input latency. I find the forced vsync by compositors annoying even when doing simple stuff like moving or resizing windows - it gives a sluggish feel to my desktop. This is something i notice even on a high refresh rate monitor.
Key word here being "might". What actually gets displayed is highly dependent on the performance of the program itself and will manifest as wild stuttering depending on small variations in the scene.
I've seen no game consoles that allow you to turn vsync off, because it would be awful. No idea why this placebo persists in PC gaming.
And you're not limited to two images. As the frame rate increases, the number of images increases and the tear becomes less noticeable. Blur Busters explains:
https://blurbusters.com/faq/benefits-of-frame-rate-above-ref...