I thought this was quite interesting too:
http://www.defuze.org/archives/171-atom-and-atompub-were-failed.html
It goes deeper than this, and to some degree both Joe and Sylain -- two folks I am privileged enough to consider close friends -- are both correct. AtomPub wasn't designed from the standpoint of creating a browser-centric publishing protocol, and instead an HTTP-centric publishing protocol. In fact one could argue that web browsers as they exist today are completely incompatible with AtomPub for the simple fact that they lack full support of the HTTP verbs used as the centralized focus for AtomPub, namely GET, POST, PUT, and DELETE.
In this regard, Joe's point is spot on: It's not that browsers have made drastic technological advances in the last seven years, and instead hackers like you and I have discovered there was more power under the hood than we all initially realized (Credit IE and the XmlHttpRequest object), began to use this power in new and innovative ways, and the browser vendors have since followed suit by taking the XmlHttpRequest object, fine tuning the API, standardizing it, to then implement that standard in varying degrees of compatibility. The end result of all of this is that browsers have a clearly defined and adequately supported standard for pushing information from client to server and back again in a way that works well /IF/ you're looking at things strictly from a browsers perspective, the most ubiquitous application on the planet. In other words, if you want to build an application with the greatest potential reach, building it inside the confines of a browser makes a lot of sense. And it's because of this that the web browser has developed a /MUCH/ longer life expectancy as far as an application platform is concerned.
But again, AtomPub wasn't designed from the stand point of the browser being the primary publishing tool. It was designed as a cross-platform, cross-device HTTP-centric publishing protocol in which any application capable of speaking HTTP could Create, Read, Update, and Delete resources on any AtomPub compliant server they had suficient access and privs to. The fact that most browsers are incompatible with AtomPub isn't something that anyone should look at as a dagger through the heart of AtomPub. In fact, quite the opposite: The browser vendors need to catch up with the rest of the devices and applications out there which speak fluent HTTP 1.1 if they are to ever be looked upon as true application frameworks instead of the lowest common denominator in which the likes of Flash, Silverlight, Google Gears, and other forms of in-browser application frameworks use as little more than a delivery vessel to push their state of the art while browser vendors seem complacent on pushing the state of the article tag and calling that progress.