Firstly, I completely agree that it's easier to flip a centralised switch, make an incompatible change to fix a security issue, and force all their clients to upgrade to continue working.
However, I don't think that decentralised solutions have to end up in the worst-case scenario we see with SMTP (or even random(4)), or the medium-case nightmare of (say) phasing out SHA-1 TLS certs. There's a spectrum of nightmare here, and you can engineer both the tech and the governance to enforce a culture of security awareness and aggressive upgrading until things move fast enough. In practice, this means:
* Set a cultural precedent that obsolete clients are a bug, not a feature, and should be killed off or upgraded.
* Ensure that the most popular clients are actively supported to implement security features. If necessary, the standards body itself should get off its ass to do the work in order to protect the integrity of the ecosystem.
* Set a cultural norm of shaming users and developers who don't upgrade for security features - the same societal pressure that generally stops people wandering around in public if they're covered with chickenpox.
* Enforce it in the largest public communities of the ecosystem - in Matrix, this would be #matrix:matrix.org and a bunch of other huge >5000 user rooms, where if one day we had to make an incompatible protocol change, it'd suddenly be abundantly clear that folks on old clients would be excommunicated until they upgraded. We believe that users would rapidly find a way to switch client or encourage their developers to upgrade if it meant they were no longer able to participate in the biggest rooms!
* It's obvious, but: layer the protocol so that functions can be swapped out easily, just as Matrix allows arbitrary future E2E protocols in addition to today's m.megolm.v1.aes-sha2.
SMTP's woes stem from innocently trying for backwards-compatibility at all costs; not layering the protocol; having no governance model or culture which shamed ancient or obnoxious MUAs into being abandoned or fixed.
Slowness of SHA-1 phase-out in HTTPS is more the community again being conservative about backwards-compatibility, and a rather cautious attitude from the browser vendors in deploying the upgrade due to fear of upsetting everyone's expectations that The Web Never Breaks. Again, if you had more of a willing attitude that sometimes there's a security disaster and everyone has to upgrade (assuming that the software mechanisms are in place to upgrade and you haven't baked into hardware etc), perhaps people would be more willing to move faster.
So, with Matrix, we're trying to instil that attitude from the outset, whilst ensuring that the tech can support it. Time will tell whether it will work :) Better worth trying than to give up on federation and decentralisation entirely, though: privacy has no value without freedom.