I am not against a decentralized set of repositories, actually am for decentralized repositories as long as it also protects code security. I offered a few thoughts here for community maintainers that decentivizes them from centralizing the official community repositories.
The good part of this proposal is the commit hash does allow for immutability for a decentralized set of repositories (as long as the validators do not install, or upgrade/update, to anything other than that commit hash once a proposal, listing the commit hash, has passed for that code). This helps strengthen and follow the pattern of 4159 suggested, and that EK has used for the L1JTF proposals, of listing pull requests in proposal discussions and in the proposal itself, so that governance and developers can review the code and know exactly what changes are being made for consideration, and the vote actually covers the acceptance or rejection of that code.
It does seem though that there needs to be development of some tools for this, since it does disrupts development (or at least it could help development if this type of a model suggested in this discussion is adopted). For instance, each project that is not the one proposing the code will have to overwrite their repo in order to start with the commit hash that is being voted on if it is accepted - so they get the starting commit hash (to establish that no prior code has been manipulated). You can’t cherry pick in Github and come up with the same commit hash (which is good for immutability of the code, but does mean you have to overwrite your repo and manually move all development from branches into the new copy of the repository with the correct starting commit hash). This actually happened for Terra Rebels, where they had to archive their repository, and fork the classic-terra repository, so they could end up with the approved commit hash that a proposal listed as official.
It is not the end of the world to continue like this, nor is it to pay some community maintainers that just pretty much hold the repos (possibly making no changes to them at all - similar to the way a mirror site of the repos with the last commit hashes that passed a vote). I am also not opposed to a project holding the set of canonical repositories, as long as it does not cause a civil war every time someone wants to change it (or maybe the last person to have a passed vote for code is the new canonical org/repositories unless they remove the commit hash, and then it falls back to the previous canonical org/repositories).
Just a few thoughts for what they are worth…