The writer of this blog is a cryptographer. They're primarily focused on security, first and foremost, and when people ask for their advice, they're probably concerned about security, too.
The Matrix devs demonstrated an alarmingly cavalier attitude towards fundamental security issues that the writer pointed out in the past, so they are naturally not going to encourage its use.
The devil is in the details on this. The core concern was that libolm (the obsolete C impl of e2ee in Matrix) used crypto primitives which don’t protect from timing attacks.
However, in practice, this was not exploitable: the only way to exercise these primitives was over the network, where network latency and request rate limiting mitigates such attacks.
Meanwhile, we had already rewritten and replaced libolm with vodozemac, a pure rust implementation using robust primitives, shipped in the major Matrix SDKs and implementations like Element and Element X.
I’m not sure this counts as alarmingly cavalier. I do regret libolm ever going into production with substandard primitives from a hygiene perspective, but we fixed it as soon as we could via vodozemac, and meanwhile included the safety warning.
The part that was "alarmingly cavalier" was when you admitted to knowing about these problems for years and not fixing them or telling the ecosystem of competing clients about them so they could mitigate their risk. https://news.ycombinator.com/item?id=41249371
You visibly deprecated Olm after my disclosures went public. When I last checked, only Element and its forks actually use vodozemac, so the rest of the ecosystem which still binds libolm was still vulnerable, and probably still is today.
The Matrix devs demonstrated an alarmingly cavalier attitude towards fundamental security issues that the writer pointed out in the past, so they are naturally not going to encourage its use.