They could, but again it's not just about the API, the client itself must also be secue enough. That means enforcing security in some way to third parties, or just blocking them until they've solved all issues. And in practice if you let people migrate at their own pace they just won't migrate until clients complain.
It's not at all clear that the messaging ecosystem would be better if Signal could say "We won't let you send this message to your friend because we think their client isn't as secure as ours."
I'm sure there are cases where a third party client would be less secure and Signal would be justified in refusing to relay messages to/from that client, but what about situations, like the current one, where it is Signal itself that is insecure? To be consistent, shouldn't Signal have to block their own client until they fixed the issue?
Even if you accept the idea of Signal having a (inconsistently applied) veto over which apps are allowed to use its infrastructure, how far do you take it? Should they deliberately brick official Signal clients running on versions of iOS or Android that are deemed insecure? Should they require that the phone manufacturer is "trustworthy" so that it doesn't risk containing Chinese government spyware?
Taken to extremes, Signal would need to come with its own antivirus scanner or support some sort of remote attestation of all the versions of all the software running on the phone, to prevent messages being leaked through side-channels. And what would that achieve, other than pushing people to use other, less secure apps?
I think it is a dangerous distraction for Signal's threat model to worry about anything other than making their own app secure, and making sure that the protocol supported by their servers is secure.
