1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone who just wants to run a program (again a great example being Python venvs, which at this point have decades of tooling built up around trying to make it less annoying to deal with).
2. For "cattle" systems having everything installed at the system level is generally not too much of an issue, but for "pet" systems where the user might be experimenting with things it's really nice to be able to install stuff in a way that doesn't affect anything outside of your user account even if it's also available at the system level. The computers that I personally operate from on a daily basis tend to build up a lot of crap I used once over time and removing it without just backing up my stuff and nuking it all can be a major pain.
It's worked for me since workstations were shaped like pizza boxes.
I'm sure there are some things it can't do, but it goes a long way. When you're installing distributed binary packages you have less ability to control the baked-in install dirs, but if the package honors the conventional $(env) it can work.
Mixing user and system software is like having Photoshop and all of your games install their files directly into the Windows directory.
...or not, and this is why HomeBrew exists and I need to learn it or ansible/etc.
comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u)