Rebooting after updates
"Why does Windows do this?"
Essentially because of one bad call back in the late 80s plus one ever-present constraint on MS that doesn't apply to Linux. Oh ... and the fact that MS can't be arsed to fix it.
The bad call was Win32's design choice to map executables into the address space rather than copying them. This meant that the underlying file remained "in use" until every stopped using it. In the case of widely used DLLs, the only realistic way to force that stop was to reboot the system. The saving was only ever minimal and would have been a saving in the system page file rather than real RAM in any case and this design choice clearly could have been made the other way. (UNIX does it differently.)
The constraint is that MS caters for the closed source market. A new release of Windows cannot break existing applications, or else no-one will upgrade. Since MS can't fix badly behaved applications from third parties (who may no longer exist), they have to maintain the semantics of bad design choices from several decades ago. You can be sure that there are widely-used applications out there that would be broken if it were possible to upgrade an executable file (particularly a DLL) while it is in use. (Amongst other things, it opens the possibility of having two versions of the same program or library running at once and they might share data with each other.)
Some other OSes have this constraint, too, but Linux doesn't. In fact, Linux had (is this still the case?) a reputation for introducing gratuitous breakage from one kernel version to another precisely to pressurise driver vendors into open-sourcing their drivers so that Linus and his friends could keep them running long after the original vendor lost interest.
In the case of system DLLs, which are the over-whelming cause of needing a system reboot after Windows Updates, I could imagine a simple EXE header flag that fixes the problem. Flags already exist to copy (rather than map) an executable if that EXE is on a removable or network drive. MS have never bothered to add a third such flag for "just copy, always, ffs" but if they ever did then the problem would largely go away. (You'd still be unable to fix old third-party stuff, but Windows Updates rarely touch third-party stuff anyway, for obvious reasons.)