Having had to migrate a 12 year old dying server this weekend, yeah, I was 24/7 strongly cursing the idiot who didn't document anything[0]. On the plus side I did get to update a bunch of stuff to more modern practices.
[0] You will not be surprised to learn that idiot was me.[1]
[1] My other servers are much better - anything that hasn't yet been properly service'd has its own `RUNME.sh` which runs whatever it is in the correct way.
Also in case of emergency, eg after a power loss or whatever, you might have to do a reboot anyway. So you might as well make sure that this code path is well exercised.
I'd rather deal with a ground hog day of the system being for the millionth time in its first day of operation, than dealing for the first time with the system being in its millionth day of operation.
Commercial aircraft need continual software updates to operate. They are, in a sense, living, breathing machines. Things like navigation and terrain databases are updated inside of 30 days.
Adding a scheduled reboot is one more item on a checklist that was already being run through.
It's counterintuitive, but performing a reboot as a scheduled maintenance item is far more risk averse than going in and touching code that has been otherwise thoroughly tested and signed off by regulatory authorities.
The chances of introducing a new bug when attempting to repair the former presents additional risk to what amounts to a convenience issue.