JSON won't resolve that issue for podcasts that you've subscribed to that don't publish anymore. That's either a cache issue from a static resource or a service issue that doesn't support the cache response.
Also, the issue with the size of the rss feed:
It all comes down to how the settings are set. Is it set to full syndication of the article, or is it summaries. Either way, JSON won't solve that issue.
JSON isn't going to fix your issue with non-standard attachments to the articles. It's going to make it worse.
The size is an issue because XML is much more costly to parse and query than JSON, in my experience. But even if that was solved, there are a ton of other more pressing issues to solve.
WRT zombie podcasts, you can't expect users to say "I'm paying for this hosting but I'm done publishing episodes". They always think they'll get around to publishing more. And in my experience, they end up letting the show go only when their credit card expires.
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.
Also, the issue with the size of the rss feed:
It all comes down to how the settings are set. Is it set to full syndication of the article, or is it summaries. Either way, JSON won't solve that issue.
JSON isn't going to fix your issue with non-standard attachments to the articles. It's going to make it worse.