Why is a restart only required on some updates?

Why doesn't Ubuntu require restarts on more updates? I know that for kernel updates and things like video drivers, it can't load the changes without a restart. But I'm curious about more basic updates of pretty fundamental packages that often don't require restarts. Things like Telepathy, glibc, gtk, etc. Why don't packages like this require a restart to be updated? Is the new version actually running right after an update?

Another example would be Gwibber. I recently received and update to gwibber via the Update Manager while gwibber was running. The update completed successfully. Would gwibber be running the new version without manually restarting it? And is that the same for other packages? (I know some like mysql and apache automatically restart on an update). For packages that don't automatically restart, can't that be somewhat of a security issue for security fix?

This comes up because I have been running OS X for about a week and almost every update requires a restart even if it isn't kernel/video driver related (as far as I can tell - they don't give you a lot of information). A friend of mine said that Apple forces restarts on most updates "just in case" it would be weird if you didn't restart. Windows is the worst because almost any install/uninstall or update requires a restart (often forcing shutdowns to take a very long time). This may be a bit broad for this venue, but why do the different operating systems handle this so differently? Or, more specific to Ubuntu: why doesn't Ubuntu follow a more strict restart policy?

Whenever you open or execute a file in Windows, Windows locks the file in place (this is a simplification, but usually true.) You may have encountered those annoying errors where you can't delete a file because another process has an exclusive lock on it. This is why whenever Windows has to update itself you need a reboot for it to take effect. Windows will queue up file replacement and deletion activities for when it next boots up (when nothing has a lock on anything.)

On the other hand, Linux has a mechanism wherein it's not the file that is locked but the underlying data on the disk that is. This may seem a trivial differentiation but it means that the file's record in the filesystem's table of contents can be deleted without disturbing any program that already has the file open. So you can delete a file while it is still executing or otherwise in use and it will continue to exist on disk as long as some process has an open handle for it even though its entry in the file table is gone. This allows Linux to replace a program completely while it's still running and then simply restart the program or just wait for the process to exit naturally. Once the old instance is killed, the old files will no longer exist at all and the new files will have taken up residence in their entries in the file table.

So, as long as a particular file is not special in some way (like, for example, the kernel image file or files belonging similarly low-level systems) the updater can usually update-in-place like this. I'm sure there are special cases and situations where this would not be a good idea, but for most cases it's fine.

As for why OS X does it, that "just in case" theory sounds plausible.