pretty much everyone relies on "core" as the repository of updates. and it only requires the main repo key holder and half a dozen people with merge authority to vanish without 'passing down' their key authority to new people to cause problems.
take the recruitment of Wladimir J. van der Laan becoming the maintainer in 2014.
currently wlad chairs/manages:
bitcoincore.org
bitcoin core github
development IRC
development mailinglist
and much more.
yes general contributors can suggest code updates but the 'merge' half dozen have the authority to accept/reject these suggestions. and then wlad has the main authority on the final release process of a node version with those merged updates, and he signs the release candidate and announces it to the wider dev group.
if he disappeared, then what can be done with the github repo becomes very limited. especially surrounding the release process of new updates.
if the half dozen with merge authority disappeared then wlad would have to recruit others to replace(IF wlad didnt disappear too).
here he explains.
https://laanwj.github.io/2021/01/21/decentralize.html..
due to the reliance and "trust" of the "core" repo. worse case that something did happen unexpectedly to the top half dozen people including wlad, the entire bitcoin ecosystem would need to find another repo of code and group of devs to trust. to become the new "core" repo of updates and bug solving. this can cause disruption of how long a new trusted release of an update can happen.
it was said over 7 years ago that people have different repos and anyone can release a node software which the community can use. but in years after, too many have trusted and relied on one repo, one brand of node, and now going back to an open network where no single brand should be trusted would take time and some debate and disruption.
also if we moved back to the scenario of not trusting one repo. that single repo cant then push forward soft/hard forks as easily as seen in 2017+. and we can get back to having the community of nodes truly use consensus to come to an agreeable way forward, rather than the trust that one repo is trusted to move forward for the benefit of the community.
ofcourse these consensus based updates are less straight forward(nov 2016 segwit attempt 1) to update the network than the mandated single repo(june 2017 segwit attempt 2) update model.
but then if an update would actually benefit the wide community, it would then get wide support for all the variable repo's to accept independently, rather than follow without choice. thus the update of the network would happen when acceptance reached a threshold by the masses.