A lot of the time patches and updates are not applied because doing so requires down time, and the systems are important for the client to keep running. However, nothing in a moodle site should be life threateningly important - and clients who shout about not doing an update because we really need it on that day, are in fact causing the issues.
We used to operate by asking the clients to nominate a day or week when it would be of less importance.. And we run multi-tenanted systems for 30+ large organisations. It was a nightmare - being nice didn't get it done. So instead, we now tell them when it is going to be offline, and for how long. Generally, they accept and inform their users accordingly, but all we do is corporate elearning, so nothing that is absolutely critical. The most recent case was a local government organisation training people to be clerks in the upcoming general election in the UK. They were about to start a major recruitment drive and online training, and we said we were taking them offline for up to 3 days. Two of those were a weekend... you should have seen the backlash! We took it offline anyway, because it was a major update (3.1+ to 3.7)... we had it done in a day, moved to a new
server and everything reinstated... the DNS took a few hours of that time.
Patches we do there and then - often out of office hours. We contract with clients on the basis we will NOT make the system available 24/7 and if there is a security vulnerability we *will* deal with it regardless of their protests.
However, even so, patches and updates slip through the net. We get them eventually, but occasionally a patch comes out and then a full update comes out shortly after. So we normally wait a while when a patch is announced. Another good reason to do so is in case there is a problem- sometimes I don't want to be on the 'bleeding edge' of updates ;)
But you're right - it would be useful if updates could come centrally. However, it wouldn't help us since we've chopped into the core code in a number of places to create a multi-tenanted system, and we have to cross check new code against code changes to ensure we can do things with little impact. Normally, it's all done on a dev
server, checked and then pushed live after that. So there is often a delay for us... but never for very long!