There was no option per say, at least on the ubuntu installed I tried many years ago. Just a popup that happened sometime before the install but after the manual partitioning if the root partition had folders like /etc /usr /var etc that were needed by the installer. Not sure if all installers do this - but I would suspect if they didnt you can just delete the folders manually before you enter the installer and pick manual partitioning option and opt to not format any partitions.
I set it up this way so that if I need to reinstall Linux, I can just overwrite / while preserving /home and just keep working after a new install with very few hiccups.
Even with a single partition for / and /home you can keep the contents of /home during a reinstall by simple not formatting the partitions again. I know when I tried years ago with Ubuntu years ago the installed asked if I wanted to remove the system folders for you. But even if the installer does not you can delete them manually before hand. Installers wont touch /home contents if you don’t format the drive (or any files outside the system folders they care about).
Though I would still backup everything inside /home before any attempt at a reinstall as mistakes do happen no matter what process you decide to go with.
The package format is almost irrelevant TBH. Most packages are not interoperable between distros due to the versions and names of dependencies. That is not something that gets fixed by a standard package format. Packages don’t even work well between different versions of the same distro. largely due to libc - anything that depends on that is built against a specific version and when you upgrade it you need to rebuild and install everything that depends on it. Similar problems exist for all compiled dependencies on a distro.
And while some packages of the same format can be installed on multiple distros (mostly those based of the same foundation) most cannot. This is what the newer package formats (like flatpack) are trying to solve - by including all dependencies inside the package.
So a standard format does not really solve those issues, so there is little advantage for one. At least not one of the old school formats. And the wars are not really over the format, they are over the tooling required for that format. At the end of the day RPMs, DEBs, and arch packages are just tarballs of files and some meta data (and there is even a tool that can convert between them - though anything with dependencies quickly becomes a complete mess). It is the build and install tooling that makes all the difference.
Linux has standards where interoperability is important. The more things needs to talk to each other the more they need a common standard to talk over. Things like X11/Wayland don’t have many alternatives as so many things need to talk over them. The only reason there are two standards here is because X11 has massive limitations that cannot easily be worked around.
For package managers applications don’t care about them. Interoperability only matters within a single distro. So people are more free to create what ever standards they want for their own distros. And when people can choose people have opinions and these opinions evolve over time. Which results in multiple competing products that effectively do the same thing.
And here is my hipotesis if the GNU project came up with a good and easy to work package manager in the early days of Linux
Probably, but creating a good, easy to work, fast and reliable package manager that meets everyones needs when you are discovering how you want it to work for the first time is extremely hard. And even if you created a perfect one at the start, requirements can change. This happened with X11, and even with package managers seeing the rise of things like flatpack, snap and appimage that all work fundamentally different from the traditional ones.