With comments like these, I always wonder if they are talking about "RSS" as a standard or about RSS as a common word for feeds in general. Because I think RSS itself is quite complex compared to Atom and the latter has been around for many years as well and is much easier to implement, so its use even might be more widespread these days.
I really like the Atom protocol, especially with the "archived pages" extension. I've used it several times to distribute common data feeds in a really scalable way. Since everything is static, the processing on the server is minimal (either return the current string buffer, or return a string from a map), and all the archived content is infinitely cacheable. it's a really simple and clever idea
I detest the use of the term “RSS” for feeds in general, because it grants mindshare to the inferior option—vast numbers of feeds have been implemented in RSS because that was what someone had heard of (and they’d probably have done it in Atom if they knew the full story). Just call them feeds, which has always been the appropriate technology-independent term.
What I say is: use Atom, unless you’re making a podcast. Unfortunately, Apple ruined everything there by choosing RSS even though the clearly-superior Atom was (just) published by the time they released their software, and subsequently continuing to not support Atom. Most other podcasting tooling also doesn’t support Atom. But every other application of feeds supports Atom just as well as RSS.
You want to know how many times I’ve encountered titles in real-world RSS feeds being damaged or obliterated due to including characters like < (most commonly from including HTML tag names in a title)? More than a few, because RSS is awful and way too much is based on inconsistent unwritten customs rather than consistent or defined behaviour. You end up with wishy-washy consensus, and clients that don’t want to change what they do because content is written using mutually incompatible conventions, so fixing one will break another. (And probably there aren’t any clients out there subject to injection attacks of this sort any more, but there have been.)
How about Atom? Only once, in a brand new client, and that was promptly fixed when I reported it, because it was clearly and unambiguously a bug, and you were guaranteed there would be no negative side-effects, because the behaviour is actually defined, and consistently implemented.
As for functionality, I certainly see articles from time to time that are courageous enough to use basic inline formatting in their titles (bold, italics, code), and you can’t do this in RSS (there’s a small chance it’ll work—probably a bug; a fair chance the markup will be presented verbatim—probably the most reasonable choice; and a fair chance the markup will be stripped—kinda problematic); but you can in Atom (because the title is a text construct like the content and you can specify the type), and it should then either work properly, or (unfortunately more common) be safely stripped by unimaginative clients.
So define whatever RSS leaves up to interpretation based on what is already common practice instead of trying to force a competing standard.
Besides there is no guarantee that people wouldn't mess up their "Atom" feeds with similar issues and complaints that their feed doesn't validate won't sway them any more than their RSS not rendering correctly in your reader.
RSS vs. Atom is really the same situation as HTML vs. XHTML. For hypertext people have generally accepted that you need to deal with what is out there and decided to standardize how to deal with garbage in a consistent way instead of asking the world not to produce garbage, which is futile. It seems Atom proponents still need to realize this.
