This kind of thinking hasn't made its way to iPhones. When it's auto-updating an app I'm not allowed to open it (separately, it seems optimized to start updating an app moments before I'm about to open it).
The only environment other than maybe mainframes that supports hot reloading is Java and that has limitations.
Linux has zero problems with you overwriting a binary (by unlinking and replacing it) while it's in use. Sure, the old version will keep running, but it doesn't prevent the update, and you'll get the new version when you restart it.
Even then there’s still downtime when you restart the executable (could be seconds, but also minutes). Preventing that is possible, too (even on a single machine), but the cost often doesn’t make it worth it.
And nitpick: I think you know it, but for others: “unlinking and replacing” is essential. “Overwriting” (keeping the inode number the same) can be problematic.
Yes, that is why /usr/bin/install exists.
No, in Android you can keep using the app right until the actual swap happens. Then the app restarts (and presumably a symlink is put in place in between). In practical terms this is zero downtime.
That the case with a mainstream operating system. Only one. All the others can count uptime in years even with regular application updates.
Every major Debian/Ubuntu upgrade asks me for restarting services due to a libc upgrade and warns of potential instability as a result of not doing a restart. Not to mention upgrading systemd, which tends to require a reboot.