alt Hacker NewsIt 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.
[2]: https://neugierig.org/software/chromium/notes/2011/08/zygote...