Matrix is a product developed by one entity that can be installed on premise and has an api. Different instances can communicate with each other. Mattermost also has it but we don't call it a protocol.
This is just not true. There are four main Matrix server implementations today: Synapse, Dendrite, Conduit and Construct. Conduit & Construct are written by entirely independent different parties; all four share zero code; and yet they all can communicate together (modulo beta-ness in some places).
(And aside from that, Mattermost doesn't have federation; different instances can not communicate with each other. Although we hope they'll implement Matrix eventually :)
Both third party implementations have beta status and all entirely independent implementations will be screwed and will stop working each time you decide to significantly change the spec in your monolithic protocil.
I know, you consider xep structure of XMPP to be a problem, 'because it is hard to orient in it', but in fact it is what makes XMPP so durable and capable to work in a real federated environment.
... between server instances provided by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1].
I can see zero problems with this decisive approach. /s
(And aside from that, Mattermost doesn't have federation; different instances can not communicate with each other. Although we hope they'll implement Matrix eventually :)