https://paragonie.com/blog/2015/12/let-s-re-think-security-trade-offs

Let's look at another example: MTProto, the cryptography protocol used by Telegram.

It's easy to pick on MTProto, since a recent IACR paper by Jakobsen and Orlandi demonstrated it's vulnerable to chosen-ciphertext attacks. However, this finding should surprise precisely no one involved in cryptography.

Despite being a constant recipient of criticism from security experts, Telegram claims that their protocol is more secure against DDoS attacks than an authenticated encryption construct. They also insist on using SHA1 simply because it's faster than SHA2.

We haven't been able to verify the claims of DDoS resistance (we don't have access to a botnet, nor do we have any intention of ever infecting anyone's computer with malware to build one), but the performance impact of protocol design is easy to conceptualize:

An AEAD construct, such as AES-GCM or ChaCha20-Poly1305, will verify before attempting decryption, and is not vulnerable to chosen-ciphertext attacks to decrypt messages.
Telegram's protocol will decrypt before attempting verification, and is vulnerable to chosen-ciphertext attacks to decrypt messages.

Telegram chose a protocol that is designed to take longer to fail than it needs to. They attempt to justify their implementation simply because they use faster (and much weaker) cryptographic building blocks.

Despite claiming that their cryptography protocol design team consists of six ACM champions and several Ph.Ds in math, Telegram still made questionable choices.