> There's still this lurking mess of RSS 0.91 vs 1.0 vs 2.0 vs Atom.
Maybe in theory, but as a heavy RSS user this has never been an issue in practice. For example, WordPress sites support both by default — RSS at /feed/, Atom at /feed/atom/, but apps like Feedly hide this implementation plumbing during normal use.
I’ll repurpose an older comment[1]. It was in response to “I doubt very much [JSON feeds] will catch on”.
> There’s little incentive for websites to change to JSON feeds when their RSS feeds are already implemented, working well, and generated automatically. But several good RSS readers added support for JSON feeds when the format was introduced and that’s all you need for it to be viable; it isn’t important if it “catches on” after that when the flexibility is there.
> JSON feeds were great for me because I generate my own feeds for personal consumption and can now do so with simpler code. I understand I’m in a minority—most people consume feeds and never create their own—but the larger point is JSON feeds may have already done their job: they exist and are supported if you need them.
It was created taking some lessons of Atom into account.
It does have a few minor advantages: multiple attachment support, more "branding" images support (author avatars, post "banners"), easier to build JSON than XML in most API backends these days. The one major advantage is that JSONFeed is easier to work with it in tandem with WebSub and other pubsub systems that assume messages are natively JSON, you can use the same JSONFeed item generating code for both pull (HTTP GET) and push (WebSub) scenarios.
Certainly even the main advantage isn't a huge reason to switch to JSONFeed if you've already got RSS/Atom feeds, but I believe the hope for JSONFeed was always that it would spark some sites/backends that don't want to support XML, don't have good XML libraries, or don't want to use their template languages to drive RSS/Atom feeds to be able to build something simpler instead resulting in more feeds overall than if things were just left to the XML-ish status quo. I don't know how successful it has been on that front, though, but I appreciate it exists for trying.
> Are there any technical reasons to use RSS instead of Atom in new deployments?
There's no technical reason. Unfortunately many CMSes still emit barely usable RSS v2. There's also the branding issue of RSS the format essentially being the name of the technology. Someone saying "I want an RSS feed" ends up with the implementer making an RSS v2 feed rather than a better Atom feed and just labeling it RSS.
Maybe in theory, but as a heavy RSS user this has never been an issue in practice. For example, WordPress sites support both by default — RSS at /feed/, Atom at /feed/atom/, but apps like Feedly hide this implementation plumbing during normal use.