Setting aside the technical point you're making, the pull-based architecture is the main disadvantage from the content-producer side. Suppose there is a hierarchy of customer acquisition:
1. You have the customer's billing information, ideally with a subscription revenue agreement.
2. Your app is installed on the customer's phone, ideally with notification permissions.
3. You have the customer's email address, and ideally you're not marked as a spammy sender.
4. Your SEO is good enough to get sufficient organic traffic.
5. Someone aggregates your content and puts it in front of enough customers for you to be profitable.
6. You publish an RSS feed, or any other fully opt-in technology where the customer normally pulls content from you, but might disappear at any point, and you have no way to re-establish contact with them.
7. Late-night infomercials, classified ads, etc.
I've probably missed a few categories, and maybe the ranking isn't perfect, but you get the idea. Why would a merchant or content producer bet on RSS when its main selling point is that the customer retains full control over the ongoing relationship?
Much as I personally love RSS, I don't see why today's internet would embrace it. Even the little guys dream of making it big, and that's why at a minimum everyone will spam you with a pop-up ad asking for your email address before they place a bet on a pull-based technology like RSS.
On the contrary, the best thing about RSS is that it works on a completely static HTTP host. All these "modern" syndication protocols require you to run some kind of specialized software/script on your server which makes things needlesly complex, resource hungry, hard to scale not to mention a potential secruity issue. RSS keeps it simple, that's a good thing.
And Userlands's RSS specified an <cloud> Element back in RSS 2.0, but the RSS Cloud API only was implemented outside Userland's products first in 2009, in Wordpress, afair, when PSHB already had mindshare.
RSS delegates that responsibility to your own, local, feed reader software, along with any sort of privacy measures you want in place. This I believe is (at the very least) quite defendable as I trust the software I run on my machine more than some random server on the internet.
The article mentions rssCloud. From a cursory glance it sounds like that's a protocol extension that lets you register a callback URL to be notified about updates (i.e. push messaging).
Based on my reading of rssCloud it seemed to lack a verification step so I'm glad to see the WebSub spec explicitly mention that. Without verification this seemed like an easy way to trick a server into sending random HTTP requests to third party services.
