Roughly speaking, the concrete disadvantages of Olm and Megolm are:
* In the current Matrix implementation, server tells the clients what the group membership is, so a server could spoof an invite to add a malicious user to a room and you'd have to rely on social mechanisms to spot it.
* There's no way to force everyone to rotate the sender key at the same time.
* On the plus side, it decentralises relatively well.
The concrete disadvantages of MLS are:
* Vanilla MLS needs a centralised sequencing function for changing group membership.
* The key bundles are much larger.
* On the plus side, only clients within the group can add new users/devices, and everyone in a given epoch shares the same group secret, so when someone rotates everyone has to rotate to participate in the new epoch.
Now, the server-controlled membership problem can be solved with Olm/Megolm if you instead have the client control the membership, using Matrix itself to define which users are authorised to be in the room, by running the Matrix DAG merge resolution on the client as well as the server. I did this a few weeks ago (in prep for The Matrix Conference next week) to show viability; it works, and has the advantage that you don't have to blow up the whole crypto implementation.
On the other hand, MLS can also be made to decentralise. DiMLS (draft-xue-mls-decentralized) isn't the only option here; DeMLS is the one we've been working with (using the Phoenix DeMLS OpenMLS fork) on the Matrix side - and works by letting MLS epochs fork and then merge again later, using puncturable functions to avoid undermining forward secrecy. This is a much bigger change; we experimented with it a few months back; details here: https://www.youtube.com/watch?v=jc7yfec3iIQ. It's promising, it works, but is much more complex and experimental.
So, TL;DR: it's possible to use olm/megolm securely (even if it's had a mixed record); I doubt strafe is doing fancy client-controlled group membership though. Separately, MLS can be used too, but it is way more complex and has its own complications. On the Matrix side we're still pursuing both (and finally making some progress, although it's a very slow burn).
* In the current Matrix implementation, server tells the clients what the group membership is, so a server could spoof an invite to add a malicious user to a room and you'd have to rely on social mechanisms to spot it.
* There's no way to force everyone to rotate the sender key at the same time.
* On the plus side, it decentralises relatively well.
The concrete disadvantages of MLS are:
* Vanilla MLS needs a centralised sequencing function for changing group membership.
* The key bundles are much larger.
* On the plus side, only clients within the group can add new users/devices, and everyone in a given epoch shares the same group secret, so when someone rotates everyone has to rotate to participate in the new epoch.
Now, the server-controlled membership problem can be solved with Olm/Megolm if you instead have the client control the membership, using Matrix itself to define which users are authorised to be in the room, by running the Matrix DAG merge resolution on the client as well as the server. I did this a few weeks ago (in prep for The Matrix Conference next week) to show viability; it works, and has the advantage that you don't have to blow up the whole crypto implementation.
On the other hand, MLS can also be made to decentralise. DiMLS (draft-xue-mls-decentralized) isn't the only option here; DeMLS is the one we've been working with (using the Phoenix DeMLS OpenMLS fork) on the Matrix side - and works by letting MLS epochs fork and then merge again later, using puncturable functions to avoid undermining forward secrecy. This is a much bigger change; we experimented with it a few months back; details here: https://www.youtube.com/watch?v=jc7yfec3iIQ. It's promising, it works, but is much more complex and experimental.
So, TL;DR: it's possible to use olm/megolm securely (even if it's had a mixed record); I doubt strafe is doing fancy client-controlled group membership though. Separately, MLS can be used too, but it is way more complex and has its own complications. On the Matrix side we're still pursuing both (and finally making some progress, although it's a very slow burn).