Pro: You aren't subject to the same-origin policy that XHR has.
Con: You can't manipulate the Request (GET only, can't touch headers), and you can't even see the Response -- when you vote on HN it just increments the number it already had instead of getting the new number in the response from the server.
Simpler client-side code. Instead of setting up an XMLHttpRequestObject and forming a traditional POST request, you request a URL via GET.
If there's another advantage, I'm probably missing it (the image switchout shouldn't require a server-side call, since we already have the up/down icons loaded in the browser)
For HN, I suspect the reason was that it was fast and easy to code. The main disadvantage in this case is that there's no actual guarantee that the request made it to the server, so if the request fails for any reason, it fails silently.
There are other advantages and disadvantages to image beacons depending on how you use them.
In the case of a search engine using them to track clicks, a major advantage is that the performance cost (to the user) of an image beacon is much lower than the performance cost of using redirect-based tracking. The tradeoff is that beacons are less reliable than redirect tracking, since users may not have JS enabled.
Also, with click beaconing, there's a race between the beacon request and the navigation event; you fire the beacon when the user clicks, but there's no guarantee that the request will finish before the browser switches navigation contexts, unloads the current page, and cancels all pending requests. An image beacon is more likely to succeed in this case than an Ajax request, since there's more overhead associated with Ajax requests.
All the major search engines use image beacons for tracking to some extent, but Google and Bing use them more than Yahoo! currently does.
What's the advantage of doing it this way as suppose to using an ajax call?