Since 2.5.1, and especially since 2.5.1.152, my hub has been running lower on free memory on a daily basis. At the same time, the CPU utilization and CPU temperature are now running at their lowest values ever, <110F and <15%.
From my Watchtower trends it appears that the periodic cleanup jub is doing a great job and that the daily cleanup job may not be necessary.
Not only is the hub running better, but it is also running better every day after the last reboot. This begs the following question, would it be possible for updates, that do not update the database structure or the base operating system, to be delivered as app updates that replace the code, but do not require a reboot to install?
I would love to only reboot the hub for major updates.
Possible, sure, but the effort to test that would mean taking significant (and limited) time from implementing new features. The engineer in me wants a reboot free solution, but I like my sleep 
My sense is that major production releases happen every few months (2.5.1 came out about a month ago - and another prod release occurred this AM), is your perception different? - I don't install Beta's on my production hubs, and even when a new release occurs, I wait a week or two for the dust to settle.. Given a reboot every quarter or so, doesn't seem like a huge ask, even if your keeping up with production releases.
Now Beta's are another story, and those seem to come out every 2-3 days, near the end of a Beta test cycle, but not sure it's worth the effort to change the software update process, if you just don't update on every Beta release (I read the release notes, and lots of stuff doesn't apply, so I skip a given Beta on my Dev hub).
Personally, I would rather them spend more time on automated regression testing scripts as part of their CI/CD pipeline, to catch more things internally, and do less frequent Beta releases. Or continued focus on memory leaks (or tools to allowusers to find them in 3rd party apps/devs) - Versus spending engineering effort to allow more "hot patching".
As always, YMMV
Basically, updates that don't have database changes or operating system upfates could be installed in a manner similar to Hubitat Package Manager.
The main difference would be that users would not see the app code or the inner workings of the process.
In my professional career, I worked with a software system that delivered all updates in a similar manner. It took a few minutes to maybe 20 minutes for big updates to install the compiled code and then to turn the access back on.
In commercial/enterprise/industrial settings, downtime for reboots/updates is typically more problematic, for a variety of reasons (though I assume it pretty much all boils down to $$$ in the end).
Victor's response seems to reinforce that notion in the sense that while it's probably possible to do this, the juice wouldn't be worth the squeeze for the staff, and that may be true for many users too based on @GuyMan's response.
I fully agree with the need for better testing. Those faults found after release can be significantly painful for the affected users.
My request was based on seeing my hub take more than two weeks to approach a steady state for free memory. Each boot will restart that process of finding that steady state.
My professional experience with the delivery of code and database updates is that after a few required manual steps were performed that needed a reboot, all updates were delivered in this manner. Both code and database.
It was only our server support people that needed to perform a reboot for some system updates.