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.
Also it is somewhat interesting that this Open Source centralised Signal server, where centralisation means you can move quicker, hasn't seen a commit in 10 months.
Compare it to Matrix Synapse https://merge-chance.info/target?repo=https://github.com/mat...
The story with the flagship clients in both spaces is very similar.
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...