It doesn't, I have installed many Windows updates that didn't require a reboot. Even ones I expected to need an update, like an update to a graphics driver. Screen just went blank, then came back a second later.
AFAICT it's only updates to things that run at startup time that require a reboot, probably because NTFS doesn't allow you to write to a file that's currently opened (as opposed to nearly every Linux filesystem, which handles that just fine: the process that has the file opened continues to see the "old" file, while any that open it after the write will see the "new" file — but NTFS, probably due to internal architecture, can't handle that and so you have to reboot to change files that background services are using).
It has nothing to so with NTFS, but all with the Win32 API. The Windows kernel supports this file model, proven by WSL1. There is a blog post somewhere (Old New Thing?) stating the engineers would like to e.g. allow deleting a file even if there is still a program with with a file handle to it, but are concerned deviation from current behavior would cause more problems than it solves.
The reason that they want a reboot is that they do not want to support a system using two versions of the same library at the same time, let's say ntdll. So they would have to close any program using that library before programs that use the new version can be started. That is equivalent to a reboot.
And I completely understand the reason. For a long time when Firefox would update on Linux, the browser windows still open were broken; it opened resources meant for the updated Firefox with the processes runnung the non-updated Firefox. The Chrome developers mentioned [2] that the "proper" solution would be to open every file at start and pass that file descriptor to the subprocesses so all of them are using the same version of the file. Needless to say, resource usage would go up.
This isn't an NTFS thing. The I/O Manager implements NtLockFile. Applications can request exclusive byte-range write access to a file. And perhaps it is lazy programmers, or defaults, but they generally do.
I don't think Microsoft sees client machine reboots as an issue, and it used to be much worse when they used to be released weekly. On the server side, Microsoft expects that you'd implement some form of high availability.
NTFS on non-Windows follows the locking semantics of the underlying driver model/kernel, e.g. you can replace an in-use file on Linux. Likewise, using FAT on Windows you cannot replace an in-use file. This is just to demonstrate it isn't a file system-specific "issue" (if you feel it is one). It was a design decision by the original NT OS/2 development group.
Ultimately, the NT byte-range locking is a holdover from NT OS/2, where in OS/2 byte-range locking was mandatory.
There a enough apps that keep old files open, but also (re)open updated files that do not fit to the old, open ones, thus have all kind of issues.
(Subjectively Thunderbird has major issues with not restarting if libs it depends on get upgraded.)
I stopped answering support mails and tickets from users with long uptime with anything else than: reboot first.
And it was >>80% the cause of problems.
And yes, most times a logout would suffice, but with our users having >100d uptime with desktops and laptops, the occasional kernel update is done /en passant/ this way.
(The impatient could kexec and have the advantage of both. Or look at the output of "need restart" or "checkrestart". But I couldn't care less in case of end user devices)
Can‘t replace files that are in-use and that includes running programs or loaded DLLs. Linux can, it keeps the inode and only actually deletes upon termination of last access.
Ive read this many times, so I tried this a few times, giving it the benefit of the doubt, only to find the PC on login screen the following morning every time.
Now, don't get me wrong, what the hell is so special about Windows that it needs to reboot for every little update operation?