The base message queue protocol chooses sensible cryptography, but leaves some important security aspects under-specified. This can lead to mistakes when implementers do not fully understand the security implications. In the context of an open ecosystem, being under-specified here also opens up more risk of implementers causing vendor lock-in (deliberately or otherwise) by breaking interoperability.
For instance, "servers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels". Exactly how that pre-sharing is performed is left unprescribed, although SimpleX proposes that clients could introduce other clients to new servers' addresses and public keys. Key distribution is always a challenging problem in cryptography, but traditional x509 PKI is not generally considered to be an issue, so I do not understand what additional benefit to privacy would be found when distributing the keys using the SimpleX protocol itself.
The overview goes on to explain how all client-server communication takes place using blocks of data fixed at 16KiB to make it more difficult for passive observers like ISPs to collude and work out which two parties are communicating. This protection is just taking advantage of statistics - the larger a block is, the more possible messages it could contain, and so the sender is more ambiguous. The downside, though, is that it's very wasteful: assuming that you need to refresh at least once per second for a text chat to feel responsive, that would entail sending a minimum of just under 1MiB of data each way every minute, which is approaching the bandwidth required for a two-way VoIP call! Such an extreme level of resistance against active attempts at monitoring is not usually required by most people, so it would seem more sensible to me to merely ensure that SimpleX is compatible with a lower-level private protocol like TOR for when that protection is necessary.
Moving on to the overview of the chat part of the protocol, I see a fairly uninteresting JSON-based format. There is nothing immediately wrong about it, but it's hardly state-of-the-art either: there's no CBOR to reduce overhead, no JSON-LD to improve extensibility, no MIME types to account for different types of attachment.
From a long-term community perspective, the seemingly arbitrary choice of sub-protocols within the chat protocol (currently group chats, file sharing, contacts and WebRTC calls) makes me hope that SimpleX have a plan in place to avoid what has happened to Matrix. Matrix has numerous built-in features (some of which are in a rather half-baked state), often with a tight coupling between the protocol and the expected user interface for the features, making Matrix notoriously difficult to implement.
Ultimately, I fully support what SimpleX is trying to do: remove the dependence on long-term, globally-unique user IDs in internet communication, which at the moment hampers even federated applications like those that use ActivityPub or Matrix. However, I get the sense from reading the introductory documents that those behind SimpleX aren't aware of (or worse, don't care about) existing standards upon which they could build, and so the novel features are obscured by a lot of rather pedestrian protocol definition that has to be implemented. I fear that SimpleX won't be able to achieve mainstream success unless it fits better into an existing ecosystem of protocols, and whilst I wish them good luck, I must admit that I'd be putting my money on W3C's Decentralized Identifiers (DIDs) to liberate us from centrally-managed online identities.