OK, I win. Add this to your AdBlock manual filters list. (And as a bonus, unbreak Apple's website too.)

http://images.apple.com/metrics/scripts/s_code_h.js
http://wwwimages.adobe.com/uber/js/omniture_s_code.js

Alas, it affected (infected?) the entire Adobe website later on. And recently, Apple implemented it site-wide too, which is what finally prompted me to get irritated enough to figure out which specific JS includes were involved and that blocking them would fix the issue.

Again, it's not even so much that they're trying to do metrics as the fact that they're doing it so poorly and with an underlying assumption that the secondary metrics server will never be unavailable. Even a simple test by the script on page load to verify that it can reach the second server—either before adding the click listener or if afterwards such that an error alert pops up when the user clicks a link instead of sitting there like a bump on a log—would be a big step forward.

So, it turns out this may be a 100% valid bug report after all!

Got this feedback on the Reddit Apple Forum when I posted up about it:

Encountered this same issue recently on a client site, and the problem is actually a change Adobe deployed in the s_code file around v25.2-25.4.

Apple needs to change "s.useForcedLinkTracking=true" to false in the config section of the s_code, otherwise the s_code click event handler goes fubar and nothing will work on the page in Google Chrome if the s.trackingServer and s.trackingServerSecure aren't returning the proper response or are unreachable - which sounds like what's happening here if you route them to localhost.

Bad on Adobe for deploying buggy code so widely used, bad on Apple for not adequately unit testing, even if it is an edge-case.