Now, there well may be technical reasons why a reboot is a bad idea, but this article doesn't present any.
hrm, the article states: ...If you shrug and reboot the box after looking around for a few minutes, you may have missed the fact that a junior admin inadvertently deleted /boot and some portions of /etc and /usr/lib64 due to a runaway script they were writing. That's what was causing the segfaults and the wonky behavior. But since you rebooted the server without digging into the problem, you've made it much worse, and you'll soon boot a rescue image -- with all kinds of ponderous work awaiting you -- while a production server is down.
and:
In many cases, it's extremely important not to reboot, because the key to fixing the problem is present on the system before the reboot, but will not be immediately available after. The problem will recur, and if the only known solution is to reboot, then the problem will never be fixed unless or until someone decides not to reboot and instead tries to find the root of the problem.
and while I disagree with this one slightly..as the problem may still be present after a reboot..I defintely agree with what the author is saying...find the actual root of the problem, and fix it..don't just cross your fingers and hope a reboot will fix the problem.
Also the author never mentions preserving uptime of the server as a goal..he does mention a few times patching in place..which will mean killing services, effectively making that particular server unavailable.