If you update a central library (e.g. openssl), you'll have to restart in order to deal with in-memory copies being used by other programs. If you're running a Debian server one of the packages to include in your base install is debian-goodies or needrestart because the former bundles a very helpful little script called "checkrestart" and the latter is an updated systemd-compatible version, both of which use `lsof` under the hood to determine when and why package updates require a restart for full effect.
But do you? You really only need to restart the processes using those packages. Technically, a kernel update (specifically security update, bug fixes may not be important) would only require a reboot.
However, I've often been in situations where I reboot anyhow, because rebooting means I'm 100% confident the old code is gone, whereas if I try to get clever and avoid the restart, I'm significantly less confident. Depending on how hard it is to validate the security bug, that can be a problem.
Plus, for much of the past 20 years for many computers, if you're going to restart all services, adding in the last step for rebooting doesn't add all that significantly to the downtime. Server-class hardware often have things that make that not true (stupid RAID cards), but for everything else you were often only adding, say, 25% for the actual reboot.
You don't need to be 100% confident the old code is gone - just 100% confident the old code is no longer exposed to the network - check your sockstat/netstat and call it a day.
It gets complicated when central libraries like glibc have to be updated.
I did this once with checkrestart on Debian Wheezy and I had to restart nearly everything except for the init process.
So in this case just restarting the system would have been faster and easier.
For lots of core stuff, you don't technically need to reboot, but you probably do need to go down to single user mode and come back up (consider upgrading glibc or openssl), and at that point you might as well reboot.