What elianda describes is called double buffering (drawing to a buffer while displaying another one, and then flipping between the two so that a frame is displayed in its entirety without the risk of displaying a portion of the next frame, avoiding the tear, which is being populated in a region safe from being read), You may not see tearing, rather other artefacts or simply a reduction in the frame rate. I don't understand why they didn't just call it 'Enable double-buffering'?
V-Sync is the refresh rate of the display device (which maybe different to how quickly the gfx draws a frame to be displayed). By syncing the two, the graphics framerate output will be throttled to match the refresh rate of the display device (the theory being there is no need to draw a frame if it is not going to be displayed, or better to have a frame ready to output when the display device requires it, rather than risk the display device asking for it while its mid flow drawing something, causing a little blip in the real-timeliness, like skipping a heart-beat).
With page flipping off (i.e single buffering) there is an increased risk of the V-Sync not matching the gfx draw frequency (especially with higher density geometry) and thus causing frames to perhaps be skipped non-intentionally (this may manifest as a reduction in FPS or performance as you have seen).
Why would it be an option? Well, personally, I've never understood why you would ever NOT want to use double buffering unless you couldn't, or for that matter use triple-buffering AT ALL (if anyone has could please explain why it was required at the time)? Quad buffering, yes, for double-buffered stereoscopic displays. However some more CAD orientated applications do not require double-buffering, and can display savage flickering (displaying an empty frame) if double buffering was enabled by default. Maybe this is an option for that? so the user can manually turn of or on double buffering? My heart goes out to the user having to perform serious work on a Rage128 Pro 🙁. Were these generic drivers for other ATi cards at the time? The FireGL was under ATi's control around about this time I believe, it may be more relevant to those cards? At the end of the day it's "another option" which may enable some programs to perform better or even work at all (and vice-versa).