The "Learning curve" argument suggests that oligopolies tend to form, so it is not worth bothering. But that applies to pretty much any organizational activity, not just federated protocols, and often people try to push back against oligopolies or monopolies; often it is desirable and possible.
The "Authentication" one only applies to web-based clients, but you can login to remote instances even with those: converse.js supports it for XMPP, for instance. Possibly not in the way the author imagines it should though; perhaps that is closer to OpenID/WebID/OAuth. Still, generally users are not meant to login to every instance directly: even with just Google and Microsoft, you do not login to a Microsoft server to send them a message from your Gmail account, as you do not login into the receiver's email account to place a message for them. Maybe this section should have been titled "learning curve" instead.
The "Search Engine Optimization" probably describes the current state of things (I am not familiar with that), though does not apply to many federated protocols (e.g., I do not want my email or XMPP messages to be SEO'd), and I do not see a technical reason for that when it may be useful (e.g., public blogging or discussions); certainly does not sound like a drawback of federation itself to me, but maybe that of certain search engines' policies.
I personally usually saw discoverability/exploration as the primary issue with both federated and distributed protocols, especially when it comes to social ones, and hoped that RDF with FOAF will help with it. But ActivityPub and Mastodon seem to handle it rather well now, out of fairly widely used protocols.