Well, let's look at the issues raised in the article.
Windows actually can replace a DLL that is in use by renaming the original then copying the new file into place. However, the Windows world prefers not to do this.
Ksplice updates the running code of your kernel (by waiting until no thread is using the function to be patched, then calling the kernel's stop_machine_run function -- the same thing it uses when loading a new module -- while it edits the object code); it doesn't touch your /vmlinuz file on disk. If you want the patches next time you reboot, either recompile /vmlinuz, or have an initscript (like Uptrack's) apply the patches at boot.
Even if you're updating just a single DLL with no dependencies, there are still potential problems since the DLL has to interoperate with previous versions of itself.
One reason Ksplice wins here is that it updates the kernel, which is a single thing, but more fundamentally it avoids this problem by atomically patching every piece of affected code at once. You could actually port the Ksplice technology to userspace, provided you do some userspace equivalent of stop_machine is and patch every process at the same time.
Even if you haven't changed the structure itself, you may have changed the meaning of some fields in the structure. If the structure has an enumeration and the new version adds a new value to that enumeration, that's still an incompatibility between the old and new.
Again, Ksplice has the advantage of updating everything atomically. But there is explicit support for having a hook to be called at patch time, that either updates all existing structures, or does something fancy to mark structures that have been updated, so you know that any unmarked structure needs to be updated before being used.
The Ksplice paper (PDF) outlines about how you'd go about writing a data structure transformer to address this (as well as talks about how to solve a host of other problems). See also the CVE evaluation, which links to some examples.
So it's not that Windows has to restart after replacing a file that is in use. It's just that it would rather not deal with the complexity that results if it doesn't. Engineering is a set of trade-offs.
which is why this engineering problem is not something Linus Torvalds personally does, but a separate company, Ksplice Inc., is working on full-time. :-)