This risk will be removed completely once TOFU and signed control events are implemented, which is planned (and was planned before this research). It's just more work than could fit in the disclosure timeline, especially because it's a large change needing ecosystem coordination.
This is the fundamental task of any secure group messenger. It has really one job: don't let unauthorized people read messages for the group. Here, Matrix has apparently accepted the risk that their group messenger can't do that job if the server is compromised. If you know where to look and your group is small enough, you can constantly watch to see if your homeserver has decided to stop protecting your group, but either way: your homeserver can spontaneously decide to stop protecting your group. Matrix, you had one job!
At the point where you accept this risk, you might as well just use Slack.
I genuinely do not understand the impulse people have to rationalize stuff like this. This is a devastating research result. It might be the most damaging paper ever published on a secure messaging system; I'd have to think about that.
So yes: we should switch to client-controlled membership management, and we've already started the work to do so. However, the Matrix spec and its implementations has always been transparent that it's up to the user to verify the membership of the room - for after all, if they don't bother verifying users, then all bets will always be off anyway. For instance https://element.io/blog/e2e-encryption-by-default-cross-sign... explicitly says: "You’ve verified this user, but they have risky unverified sessions logged in! A room containing any red users is shown as red." I'm not sure this exactly counts as a research result, let alone a devastating one.
However, totally agreed that we can improve on this, and we're on the case.