And, as an addendum, all this ties directly into your mention of <img/> versus $ajax();
First of all, that very mindset is the foundation of the bloat we see everywhere else. Complicate a non-problem with a non-solution, because behind the trend is really a desire to shun open standards, in favor of obfuscating intellectual property as an effort to lock user behaviors, and prevent scrapers from ripping off designs that aren't even innovative. An example of the backlash against this sort of thing was the re-adoption of semantic and/or restful URL paths, because so many back-end goons were packing query strings with hundreds of CGI variable parameters, to control page state that no one could paste or email links to each other, and even advertisers started framing a renormalization of URLs under the SEO buzzword, because they saw their page rank taking hits from the drop in sharability.
Second, once you introduce $ajax(), not only does backwards compatibility hang in doubt (as you mentioned) but cross-browser compatibility and forward compatibility may also be sacrificed. Not to mention, you branch into an entirely different area of development. Because in order to make sure everything works everywhere, all the time, you'll need an ajax library, but which one? Choose carefully, you may seal you fate, if the maintainers disappear. Not only that, any JS error for any reason at all, including async resource errors, could kill alllllllllll of your images. So now we need unit tests and a QA team? Is that right? Gee, why not just use <img/> tags, like every browser has supported by default, since... oh... the mid 90's?