the main point is to separate publishing and distribution, making publishing far more accessible and decentralised. for that to happen, I guess, from a publisher's point of view, the system should be pull based. of course we can have hubs and relays to add pull-based mechanisms to ease the load of the system.
p.s. even in that case, strictly speaking, yes a pull-based system, or even a hybrid one, will always require more work than a fully push-based system.
Oh, I completely agree with that assertion: Static content hosting is much easier than stateful subscription management, knowing which aggregators to post to etc.
I just think that this does inherently put more work on the subscribers, and there's no real way to do it efficiently in a relatively flat architecture (with subscribers directly polling publishers). WebSub helps with pure distribution, but not with aggregation (e.g. to allow keyword/hashtag search), for example.
That doesn't mean it's not worth still designing a system like that (in my view, the benefits are significant!), but I wouldn't call it a performance win.
but I suspect aggregating / indexing / etc. still is going to be the most resource consuming part of a push-based system if you want your content discovery to not be limited to two-way interactions, which means the gains of a push-based system, in terms of performance, shouldn't be that much (I suspect the main gains will be in realtimeyness instead).
In a pull system, you are at the mercy of your consumers' refresh rate setting, and for infrequent producers, you'll have lots of wasted cycles fetching nothing new on top of that.
I do agree that pull is simpler to implement (since subscription management is handled entirely on the consumer side, requiring no network protocol and server-side state for it), but in terms of network calls, it's strictly worse.