Huh? My computer doesn't do that. Rarely, but on occasion, I'll see FR's in the 45-49 range with vsync on. I also never see stuttering.
Triple buffering or adaptive vsync which is nvidia proprietary tech gives more flexibility to the rates.
Basically however it goes like this (partially ripped from another forum):
Vsync synchronizes the buffer swap with your monitors vertical refresh rate. If there are the usual two buffers (double buffer) your gpu is being held up untill a buffer swap can be made (if your GPU is fast enough that is). So if your GPU can't draw the buffer full on next refresh it will have to skip it totally. If you're refreshing at 16ms intervals but a frame needs 17ms to draw, it will miss the sync interval. Because the buffer swap is locked to the refresh rate it can't take place on the 17ms mark - it needs to wait until the next interval, which will be at 32ms. Likewise if a frame needs 33ms it will miss the intervals at 16ms and 32ms, and will need to wait until the 48ms interval.
This is the why and how vsync effects framerates. AH2 is supposed to enable triple buffering automatically AFAIK but I have noticed that in some cases I had to force it on from graphics settings.
Judging from Changeups post though it seems that some of AH:s stutterings do not result from lack of rendering power but instead AH has trouble with i/o implementation. If software code is made 'blocking' like it naturally happens when you use loops etc. any operation will force the code to hang for the duration of it. Since i/o is natively very slow, making i/o operations blocking can cause very visible stutters since the software basically stops working for the duration that some texture is loaded. Coincidentally this plays together with vsync so that even if a small texture block needs i/o it's enough to make the rendering skip a frame or two leading to visual problems.
There is a solution to this which is called 'non blocking code' which essentially performs parallel operations so that loading textures does not hang the main code at all - but this type of code is much more demanding and any software title that has roots years back usually doesn't make use of it.
The problem with old software projects can be that the main codebase is so massive that the legacy stuff in there is just too resource heavy a task to do on a tight budget and time frame.
I'm not saying this is the case with AH as I have no knowledge of it, but it can be the case.