Sorry, I mis-understood your vote example.

But on the same train, if you're proposing (for example) that voting would work the same, without the full page load, then you've added nothing to the user experience, and 'maybe' only reduced the sever load a wee bit. I say a wee bit, because voting probably counts for a very small fraction of the site traffic. I'm sure the load is the result of casual browsers, not hard core voters (numbers anyone?). With AJAX voting as you've suggested, there's still the question of cb, xp vote counts and 'new' replies to the node you're currently viewing. These are updated with the full site request. The AJAX voting would have to either request and return this information as well (making it nearly as intensive request as a full page) or resort to additional requests to update the information (again increasing load). IMO your vote scenario is at least as load intensive if not more than the full site request.

Of course, if you're talking about voting in the voting booth (not on nodes), then I'm trying to compare apples and oranges ;) I think the voting booth would be an excellent candidate for mixing AJAX to reduce server load. I also think using AJAX to update individual node votes (as I originally thought you intended) would also be a positive user experience, with a nasty load price.

I think the cb could really benefit from AJAX. I'm not a big cb user, but I like to keep my eye on it while I'm reading nodes. I've always found it 'dis-jointed' to see the conversation skip along with each new page request and a real time flow of comments would be sweet. But doing so would replace the occasional page refresh with a constant nattering of AJAX 'pings' that surely will load the server even more. On the other hand, cb doesn't require any authentication to 'view' it, so overhead could be reduced.

But I stand by my point that AJAX if used should be for the benefit of the user experience, and arguing that it reduces (or increases) server load is misdirection IMO.