How they're different (part of the answer)

Microsoft has historically been concerned about corner cases with changes to core system
software or its configuration†, so they nearly always trigger a reboot on updates or major
config changes.

Unix (and thus Linux) has historically assumed that the operator knows what they're doing, and
will choose to reboot if its appropriate.

This bites both ways, you can get mysterious problems which resolve when you reboot your Unix
server, only for you to realise days, weeks or even years later that the cause was a daemon
still using configuration from a file that had been updated and just not re-read.

Meanwhile your Windows administrator cousin finds that despite her best efforts she's losing
an hour a month to reboots for changes that would most likely have caused zero downtime in
Linux.

† This is a self-fulfilling prophecy of course. Having decided that it's OK to handle such
changes only by rebooting, more and more of the system software comes to rely on this
behavior, and so when Microsoft did try to respond to feedback about "too many reboots" it
struggled to do anything about them. In particular the inability to replace a file while it is
open, combined with the requirement for many core services to hold open files they are using,
results in Windows needing an entire boot-time subsystem dedicated to replacing such files
while there's still a chance, and of course anything which uses this subsystem requires a
reboot...