Just because the root filesystem is RO, it doesn’t mean you’re left in an entirely read-only system - writeable partitions (either mounted directly to violate paths, such as /home, /var, et cetera, or via some kind of overlay FS approach) do exist.
The key differentiation is that the core OS - not including custom installed packages in most cases, albeit e.g. NixOS takes the atomic OS to a different level - is immutable aside from OS updates, therefore should any kind of shit hit the proverbial fan, restoring to default OS settings is as quick as a reboot without the write-enabled partitions being mounted (or simply wiping those on boot).
Your data, however, is your responsibility. You mount it separately from the OS because it is truly separate. You’re modularising your workflow here - the OS provides simply the base software interface to your hardware, and does so in a separate layer, while your own software and data are another segment you don’t want to mix with the OS.
Protecting that data is up to you - proper backups, 3-2-1 approach, etc. - the idea here is to separate concerns of the OS root fs and your data.
But by separating the two, and making the OS atomic, you’ve essentially locked yourself into a situation where, should anything go wrong, you can restore your data and your OS separately, and not be exposed to the very thing OP meme’d about - the rootfs being corrupted within days of restoration, taking all your data with it.
Just because the root filesystem is RO, it doesn’t mean you’re left in an entirely read-only system - writeable partitions (either mounted directly to violate paths, such as /home, /var, et cetera, or via some kind of overlay FS approach) do exist.
The key differentiation is that the core OS - not including custom installed packages in most cases, albeit e.g. NixOS takes the atomic OS to a different level - is immutable aside from OS updates, therefore should any kind of shit hit the proverbial fan, restoring to default OS settings is as quick as a reboot without the write-enabled partitions being mounted (or simply wiping those on boot).
Your data, however, is your responsibility. You mount it separately from the OS because it is truly separate. You’re modularising your workflow here - the OS provides simply the base software interface to your hardware, and does so in a separate layer, while your own software and data are another segment you don’t want to mix with the OS.
Protecting that data is up to you - proper backups, 3-2-1 approach, etc. - the idea here is to separate concerns of the OS root fs and your data.
But by separating the two, and making the OS atomic, you’ve essentially locked yourself into a situation where, should anything go wrong, you can restore your data and your OS separately, and not be exposed to the very thing OP meme’d about - the rootfs being corrupted within days of restoration, taking all your data with it.