You keep referring to "JSON," but the parent post referenced "JSONFeed." The question you should be looking at isn't whether JSON is somehow better than XML in an objectively measurable way; it's whether JSONFeed is somehow better than RSS in an objectively measurable way.
And in fact, JSONFeed does resolve that issue for podcasts that don't publish anymore, because it has an "expired" key that indicates that. One of the other problems that the parent post mentioned has to do with pagination, and JSONFeed handles that issue, too -- which again, RSS doesn't. JSONFeed also supports attachments in a better fashion, allowing for alternate representations of the same thing (e.g., different audio formats). Extensions are baked into JSONFeed rather than being a slightly dubious hack. The spec also supports things that have become common in the last decade-plus that RSS and Atom simply don't handle, from simple things like including favicons and banners to real-time notification endpoints.
JSONFeed has come up before on HN and the same kind of "why do you think it's better because it's JSON" questions came up. I guess we can argue about whether the bike shed looks better when it's painted with braces or with angle brackets, sure. But it's not the JSON part that makes JSONFeed better; it's the "we've thought about what we've learned in the 16 years since RSS was last materially updated" part that makes it better.
"JSONFeed has come up before on HN and the same kind of 'why do you think it's better because it's JSON' questions came up."
If JSONFeed has practical improvements over RSS/Atom, they've done a terrible job of promoting that. The initial (and to this day only) blog post and the intro to the spec imply that the only problem JSONFeed is trying to solve is to avoid parsing XML, which is just not a problem to many developers.
And in fact, JSONFeed does resolve that issue for podcasts that don't publish anymore, because it has an "expired" key that indicates that. One of the other problems that the parent post mentioned has to do with pagination, and JSONFeed handles that issue, too -- which again, RSS doesn't. JSONFeed also supports attachments in a better fashion, allowing for alternate representations of the same thing (e.g., different audio formats). Extensions are baked into JSONFeed rather than being a slightly dubious hack. The spec also supports things that have become common in the last decade-plus that RSS and Atom simply don't handle, from simple things like including favicons and banners to real-time notification endpoints.
https://jsonfeed.org/version/1
JSONFeed has come up before on HN and the same kind of "why do you think it's better because it's JSON" questions came up. I guess we can argue about whether the bike shed looks better when it's painted with braces or with angle brackets, sure. But it's not the JSON part that makes JSONFeed better; it's the "we've thought about what we've learned in the 16 years since RSS was last materially updated" part that makes it better.