I don’t particularly enjoy waking up to all my programs are closed because Windows decided that tonight was the night that it restarted.
It’s slightly better on MacOS, where programs using MacOS-specific APIs can restore their state on startup, but that doesn’t include most of the third-party applications. But MacOS doesn’t force the reboot. Yet.
Besides, it's a trend that I expect to see reversed soon enough, given the direction in which Linux desktop is heading nowadays.
Edit: empirically, what has greatly simplified my life in this matter is being old-fashioned about partitioning. I keep /home and /opt separate, so upgrading typically consists of saving a list of packages, wiping everything but /home and /opt, doing a fresh install and reinstalling the packages. Depending on what I'm installing (OpenBSD on my laptop, Debian on my desktop) it takes about five minutes of accepting defaults and waiting for progress bars to fill, then another ten minutes until the packages installs (most of those ten minutes is spent on LaTeX, to be honest).
You might want to try a rolling release distro, something like Antergos (Arch + Tweaks)
Linux doesn't lock files; instead it creates in-memory copies of them. So the updater can update the on-disk version without any troubles. But if you think about it, it has the exact same problem: until you reboot, your Linux box is still running the known-buggy code.
So there's absolutely no technical reason Windows needs to reboot more than Linux. The only difference is that Linux developers decided "meh, the user can reboot when they want". But unless you reboot after installing your Linux updates, your computer still has the bugs.
This has not been true for some time, and not in any mainstream distributions currently that come to mind.
If you meant forced restarts at a given time (or whatever windows 10 does) then you're right. For now, and hopefully forever.
The complaints about this lifecycle model from app developers is that is hard to program for. Windows 8 was also strict enough forcing this lifecycle (closing out applications sometimes seconds after minimizing and attempting to restore them quickly on window restore) that it showed how bad developers can be at programming hard things like proper app lifecycle management, so they begged Windows to be less strict about it.
(That was one of the magic things about Windows 8 that Windows 10 doesn't quite replicate: minimizing a properly built application and watching the application's memory and CPU usage quickly drop to zero.)
Of course I know the reason - that's because my machine is memory constrained, I routinely run on ~90% RAM usage. But hey, that 8GB of RAM isn't here for vacation, it's to be used.
Personally, I find the mobile app lifecycle - which is where they took the idea from - to be incredibly annoying. I like to have control both when applications die and when they start up (which, on Android, is utterly unpredictable).
I have a "metro" style SSH application, and windows regularly decides it should close it, which kills my active SSH sessions.
I understand that they removed the ability to opt-out to force developers to change to a more appropriate model, but there are cases where a task cannot be suspended (because, for example, it's interacting with another computer). Having to re-log-in to my ssh session the 4th or 5th time in an hour is absolutely infuriating.
The support for background processes continues to improve. Windows 10, for instance, now supports a "single instance" background processing model where background processes can be seen as an invocation of the UI app (if already running) and vice versa (the UI app is presented as an invocation to the background process if that is already running) with hand-offs from one to the other, simplifying the programming of some of the interactions between background and UI for some apps.
