The GPU is being limited by the FPS sent to it. I've noticed this within the last few months using GPUTweak by Asus when I got even deeper into analyzing my system after upgrading some hardware. So with the XP version allowing so many more FPS in game, the GPU is being utilized more and is yielding those skewed results. If you could find a way to choke the VP FPS back down to what Windows 7 was getting, you'd see similar results in the GPU between the two (you just can't choke it down with things like nVidia forced AA as that will roughly double your GPU utilization on it's own and outside of what it really needs to process the requests from VP).
I actually started using this aspect / finding to get smoother play overall when using forced AA by actually decreasing my FPS for some tables so that the GPU card was not getting pinned or staying up close to 90-100 % (used the alpha slider mainly but some games I actually copied a dozen or so primitives just to bring it down to ideally tune the FPS to be in the range that didn't push the GPU above the 80% range while still keeping it as high as possible).
Summary of all this is that GPU is totally tied to the FPS VP is throwing at it and with just the GPU usage stats, can not be used as an indication that it is the problem.
A couple things about peoples reports, pretty much everyone with v-sync enabled is going to get smoother play and I think that's skewing the reports / perception of reports especially when people are leaving out that detail. However, v-sync may still not work as it's supposed to sync with the monitor refresh rate and it's not likely going to work as it should when the game on it's own can not perform above 60 FPS and the monitor is going to be 60 (Hz) - or even higher. I think you'll need the low poly version / a system where you actually get above 60 FPS (albeit possibly choppy) before v-sync will smooth it out for you, otherwise you're trying to sync to a level that is already not attainable.
And v-sync will throw off flipper shots on any table that has flippers with speeds around .7 or higher (including this one) – thanks Teppo for corroborating and re-iterating this in one of your earlier posts. However, that was mainly because it brought down the FPS so much (60) and the same issue could be witnessed on tables without v-sync if they were slow enough (I first saw it a couple years ago on JP's first White Water release with all the alpha ramps - I'm sure some of you also saw it too, with occasional crazy shots to the side that weren't at all where you were expecting it to go?). So the v-sync just brings the FPS down as part of it’s function / nature and it appears any table playing less than about 200 can cause the erratic flippers. BUT and a big BUT here, it should follow that with this table being already low in the FPS, that the v-sync / low FPS flipper oddities will be present in either case and therefore won't be any worse for that reason to throw on v-sync and smooth it out a bit. Still, somewhat perplexingly, with that following the logic I still seem to get a few more erratic shots with v-sync on this table even then without (but still do without it on) and need more testing to confirm some things with more certainty (will likely build a test table to confirm / demonstrate all of these v-sync / low FPS / flipper erratic (wide) shots issues).
Lastly, outside of the Windows XP / 7 thing, does it seem like more people with AMD are working more fluidly or is just that those are turning out to have the v-sync "fix"?
And Scott, none of this is a comment about your table at all and just the nuances that are being introduced with it being more demanding due to it being really, really, ridiculously good looking 