DeWitt Clinton has a good article about why you -- i.e. "we" -- should use Atom over RSS:
If you’re a human then you’ll probably have no problems spotting that the first one is plain text, the second one is XML-escaped HTML, and the third is HTML wrapped in an XML CDATA section. If presented in a web browser, in a HTML <div/> tag perhaps, then a human will have no trouble interpreting the content.
But if you’re a computer, it isn’t quite that easy. To a computer, the contents of a RSS <description/> element are opaque. The best a computer can do with it is hope to render it for a human to interpret.
...
What if you added semantic microformat markup to your HTML? If you’re using an opaque data format, then you may as well have spared yourself the effort, as no client will know it’s there.
Or what if you wanted to put some other structured data in your syndicated content feed? Geospacial data, perhaps. Product data. Or perhaps Google’s GData format. If it’s syndicated over RSS, no one will ever know.
So the problem is that the RSS syndication format is that it is lossy. Lossy insofar as information you had when writing the data is lost when it is passed over the wire.
...
My recommendation to application developers today is to use Atom 1.0, not RSS, as the basis for your content syndication.
Alas, commenter Kosso finds the key problem with using Atom:
Does Atom support enclosures. And multiple ones at that?
If so, I would look at creating a toolset to podcast in both formats.
However, that does not mean feeds won’t be broken. So many publishing tool are broken. RSS is ’simpler’ than atom.
...
I don’t want to fan a feed war, but I want to judge by trying to build a feed publishing tool which works.
BlogMatrix will always have a podcasting component (i.e. adding attachments to posts) and that means until Apple's iTunes accepts Atom feeds, well, RSS it is. Afterwards ...
