I wish that the author had spent more time really thinking about _why_ communication has moved away from email, or why XMPP/IRC never really caught on despite being vastly older than these app competitors (hint: it is because they are federated, and so making sweeping changes to the protocol/client in the name of UX becomes intractable.)

It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time, but why can Matrix solve this problem if XMPP cannot? Signal just works.

"It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time"

If you ignore IRC...

"Signal just works."

It also contributes to the fragmentation you complained about, because it is closed -- no federation, no third party clients, not even a web client. If you are on a platform the Signal team does not have time to deal with then there is no option for you. If you have a specific need that the Signal team cannot take the time to support, too bad. More problematic than lacking federation is lacking any third party client software.

Whenever I confront developers about this the conversation usually results in someone demanding a specific example of a user need they are not meeting; if I give one, they say, "Oh, we are planning that, but we first need to do $XYZ!" and if I say "there are needs we may not be aware of" they say "Well we are trying to do $this or $that, we can't solve everyone's problems!" As if users who have unusual or overlooked needs deserve to be cut off from everyone else...

Signal is still an improvement over other non-federated messengers in that it's open-source, so you actually can try to improve the situation, although it's notoriously difficult. As an example of more platform support: https://github.com/signalapp/ringrtc/pull/12

signal-cli is an example of a 3rd party client which is tolerated for now: https://github.com/AsamK/signal-cli

The main problem right now is that they don't have enough developers to take care of everything, but it's not specific to centralized services (no developer == no code). If you care about it, you can develop your own client using their library (à la signal-cli).

Regarding your last paragraph: I could probably list 20 features I'd like to see in Signal. That doesn't mean I want somebody implementing them with no guarantee about how securely they are implemented. One of the main goals of Signal is to provide guarantees against dragnet surveillance, and that constraint takes precedence.