Zulip uses standard TLS encryption, where the messages are encrypted in transit, but the server has access to the messages.
The server having access to the messages is extremely useful for many key features. Access control policies. Search. Markdown rendering that can make guarantees to clients about its behavior. Mobile notifications for mentions. And many more. There's options for all of these problems, but it's /hard/ and you end up having a lot of risk of nasty bugs where "all the message history become unreadable" and a lot of performance issues.
This is why why end-to-end encrypted messenger apps like Signal are extremely minimal with basically no chat features, and can take a while to load long conversations ... there's a lot of expensive cryptography happening in the background. AFAIK it's not realistic to use the Signal protocol with the volume of messages people do in high-traffic Discord or Zulip communities.
Some other E2EE chat systems have more features but fail to actually provide end-to-end security. (For example, the server provides the source code for the web app and can freely modify that code to steal all the messages the user can still read, or the server is still in charge of metadata like channel membership ... so a malicious server could just add a fake user to every channel).
You get almost all of the security benefits of these "E2EE" chat systems by having a trusted person self-host the server, and setting a message retention policy if you want messages in certain channels to be automatically be deleted after a period of time.
Our vision for Zulip is not billions of people on our Cloud service. People should own their own communities, not corporations. And in that world, usually the person who runs the community can be trusted to host it.