The best part about XMPP, or rather "protocol not service" as the OP discusses, is that you can go beyond the intended use case of it.

My favorite example - Arista network switches can be clients on an XMPP server. Control plane's have to be very slim. XMPP enables someone with a network operator to apply wide, symmetrical configurations across a network, without repetition. You can add the "core" switches to a group chat, and query them for information simultaneously.

Found an example article: https://jonw.mayhem.academy/arista-switch-wrangling-with-xmp...

You would never see Discord as a control plane management option, nor a Slack, Telegram or Signal option. But if all or a group supported XMPP, there would be a low resistance avenue for that (if someone really wanted it).

As it stands, we have product lock in due to each service having it's own system, with limits on interactivity. So I won't be cross-channel quoting outage causes directly from the switch in the company Slack any time soon.

Discord/Slack/Telegram get used for botnet command and control, and this method has been used since the irc days.