If you're doing consumer chat with friends and family, I'd recommend Signal over Matrix or Zulip.
For a community: A lot of communities want anyone in the public to be able to join their spaces and read their channels. For that use case, E2EE makes the chat system slower and less usable, with limited security benefits over using web standard encryption.
What E2EE may protect you from is a malicious server operator reading the organization's messages. If the server operator is a leader in the organization already, that person may already be directly a recipient of all the interesting messages anyway. The practical benefit I see for E2EE in Zulip is mainly for Zulip Cloud or other settings where a third party is hosting the Zulip server for you.
As for decentralization, a self-hosted Zulip server only talks to external infrastructure for sending notifications (Emails, mobile push) and to implement user-controlled features (E.g., outgoing webhooks). The Zulip API is fully documented, easy to understand and implement, and has community-developed clients.
Maybe you're thinking of federation? Matrix has fancier mirroring functionality, which can be important if your use case requires sharing dozens of channels with dozens of other servers. But Zulip is supported by Matterbridge and has various nicer mirroring integrations for sharing a channel with another server on various protocols.
But I don't know of many use cases where the usability of the core chat system isn't far more important than the usability of federation features.
Signal is a non starter. Never had an account and barring major architecture changes, I never will. Weakly secured centralized control of metadata with no option to self host your way out of it, and a requirement of a phone number which makes it a non starter for friends in countries that have good reason to be anonymous.
Zulip is at least self hostable but all private conversations in plain text on the server and lock-in to only being able to access chats on the one server are also both non starters. It is not a matter of trusting the admin, it is trusting that the Linux server was deployed with no exploitable flaws, and the admin never gets a court order. Too much trust for me.
Zulip is maybe a nicer UX alternative to IRC, but it is not comparable to Matrix.
Zulip's topic focus chatting get the work done and kept information organized, very easy to search and assign tasks.
That's huge upgrade over IRC since information is organized at the protocol level.
i agree matrix is desirable to replace slack only in case of where E2E is necessary.
For companies, inspection of chat logs may needed by top management in case of dramas.
For a community: A lot of communities want anyone in the public to be able to join their spaces and read their channels. For that use case, E2EE makes the chat system slower and less usable, with limited security benefits over using web standard encryption.
What E2EE may protect you from is a malicious server operator reading the organization's messages. If the server operator is a leader in the organization already, that person may already be directly a recipient of all the interesting messages anyway. The practical benefit I see for E2EE in Zulip is mainly for Zulip Cloud or other settings where a third party is hosting the Zulip server for you.
As for decentralization, a self-hosted Zulip server only talks to external infrastructure for sending notifications (Emails, mobile push) and to implement user-controlled features (E.g., outgoing webhooks). The Zulip API is fully documented, easy to understand and implement, and has community-developed clients.
Maybe you're thinking of federation? Matrix has fancier mirroring functionality, which can be important if your use case requires sharing dozens of channels with dozens of other servers. But Zulip is supported by Matterbridge and has various nicer mirroring integrations for sharing a channel with another server on various protocols.
But I don't know of many use cases where the usability of the core chat system isn't far more important than the usability of federation features.