Earlier quoted context omitted.
If next there is "Synapse Pro" that is proprietary and sold by Element and includes features not present in the open source version of Synapse but relevant to company or government use of Matrix, the AGPL-only version of Synapse will lack those features. This will hinder companies that (potentially) require "Synapse Pro"-features from contributing to the AGPL-only version of Synapse. We have seen this happen before.
This situation is no different than it was when Synapse was licensed under Apache, though.
It's a shame though because this change feels like it's weaponizing the AGPL to make the code harder to use rather than relying on the AGPL to preserve software freedom, and it's a shame because I think a more nuanced and limited contributor agreement with narrower permissions could potentially have the opposite effect and be a highly positive change and a highly credible commitment to keeping the project Open, without closing off any of the revenue opportunities that Element seems to be chasing.
I will push back a little though on the idea that nothing is different at all. This change also has the side-effect of giving contributors fewer rights over the code they write themselves. It's not clear to me whether the copyright assignment here means that the contributor is also bound by the AGPL for the code they themselves submit. If that's the case, then this is a meaningful reduction of contributor rights. I think the GPL works best when it is a universal mutual agreement by all parties to keep the code Open to everyone under the same terms; not when it is used selectively to close off specific rights of only specific parties.
But as it stands, without a CLA I could write the same code for both Element and a more permissive fork of Element and I could choose to relicense the code I offer Element to allow for the more permissive use. With a CLA, I don't know that I can do that.