Could you expand on what you found particularly compelling about the protocol / API, and also how that's changed your software development approach?
In my own view it's a much more robust way of architecting communication: the server(s) should assume that remote parties will be off, and remote parties will come and get what they want at their own pace and time. Maybe they won't receive a few messages immediately but can immediately retrieve multiple when needed. With a stretch you could see a parallel with Kafka: instead of trying to send stuff to consumers as soon as it is produced, just store it, and when clients are up they'll process stuff.
From a technical standpoint, there are six specifications (Matrix, Mastodon, XMPP, SIP, SMTP, Microdata) that have gotten the "future of the internet" partially right, in my opinion. Some union of the them, excluding the unfortunate bits, is likely the email/Twitter/Facebook/what-have-you killer. Putting that in consumers' hands and getting them to use it is another story, but we do have the starts of a technical/back-end answer.
For example, you could embed text document edits inside of Matrix messages as Microdata (ignorantly spamming someone aside with thousands of character edits aside). Is your spouse doing their taxes? Send them a chat message with Microdata explaining to the form where the attached document goes.
As a general goalpost, WeChat (having circumvented federation problems) in China is a really great example. You can pay for food at a hotdog stand on the street with chat. Uber merely facilitates communication between taxis and commuters. Whatever the project(s) you are referring to, software usually ends up solving communication problems. Recursively simplify your problem, ultimately realize how communication fits into it, then work your way back up to your initial idea. Federated IM is ludicrously powerful and, especially with graceful degradation, can lead to some sales leads.