The Signal team has always been open about the reason why they reject third-party clients: they claim that XMPP adoption was hindered by the inability of a user’s software to know if the software on the other end supports the same feature set. XMPP had grown into a large set of features that some clients supported and others did not.

If Signal introduces a new feature, it knows that all users’ devices will support that feature, because its own software is the only game in town.

Backwards compatibility against a previous set of features isn't easy but it's certainly not impossible and graceful degradation is a thing.

It isn't clear if graceful degradation is possible in a security app.

There have been tons of problems with that concept and TLS

Cases where a client is completely broken are never the problem: users will be forced to switch to a different client. It sucks, but it's no worse than the current state of affairs. A security-mandated change in protocol/behavior would fairly fall under that category.

You can always define backwards compatibility that only goes to a certain lowest common denominator feature set, and no lower. For instance I have a number of httpd that support TLS1.2+ and specifically disallow SSLv3, TLS1.0 and TLS1.1. The population of browser user agents that don't understand TLS1.2 is infinitesimal at this point.

Ironically OMEMO for XMPP ended up being based on the Signal protocol.

They also time bomb their own software, so if you don't take automatic updates from them it just stops working.

[Yes, you could manually compile it and update it... which is what I did for the first year I used signal, until it expired on me with no warning while I was away on a trip and had no way to update it.]