The common cause is “rolling your own protocol”. At the time when #Threema first released, the space of messaging protocols was still pretty empty, but OTR (from 2004) did already achieve forward secrecy. Threema is entirely built upon NaCl, the cryptographic library by Daniel J Bernstein. It was interesting to see, when talking to the team, that some of the bad design decisions (such as not authenticating the metadata of messages) arose from limitations of the #NaCl APIs. Another point to be made is that a company whose main product is based on cryptography, should always have a cryptographer at hand to assess its security and to propose already-existing protocols when possible, for example the battle-tested TLS instead of creating their bespoke client-to-server protocol.
The Threema protocols lack(ed) basic properties that are nowadays considered de rigueur for a messenger app to be regarded as secure: forward secrecy with respect to a malicious server, and protection against replay, reflection, and reordering attacks. While developers mostly stopped “rolling their own” cryptographic primitives, rolling your own protocol can be as dangerous: the recent attacks on Mega and Matrix are also an example of this. We need more provable security, and more scrutiny for cryptographic protocols before they are deployed.