If Windows Server has been developed in such a way that a patch would just randomly reboot in the middle of the day or if anything would just reboot it unknowingly to the ops team then this is an OS problem and a reason why Windows Server is unfit to be used for servers rather than a patch problem.
A patch should be released as soon as possible and the OS should make it possible for the OPs team to install a patch at their own convenience and then there is no reason to withhold a patch ever. Sounds like a fundamental Windows issue and not a business practise issue.
I fundamentally disagree with your point of 'a patch should be released as soon a possible'.
A patch releases the fix, but by necessity also puts a bright target on the vulnerability it fixes by providing the information on potential exploitable vulnerabilities in the system being patched. From that moment on it is a race between reverse engineering exploit writers and system maintainers to get their work done first.
Having coordination and predictable planning where possible allows companies to include security maintenance into the workload, rather than to have to constantly scramble and react to unforeseen and unpredictable wildfires.
It is not about 'convenience', it is a component of a mature security process.
A patch should be released as soon as possible and the OS should make it possible for the OPs team to install a patch at their own convenience and then there is no reason to withhold a patch ever. Sounds like a fundamental Windows issue and not a business practise issue.