Once upon a time it was popular to laugh at package systems like RPM and say that all you really needed was 'make install'. This attitude missed the point, because the importance of good package systems is that they let you easily remove things.

This matters because it encourages experimentation with packages. If removing a package is difficult and painful, it's a fairly big commitment to just install a package in the first place. If removing a package is easy and reliable, then installing packages is not at all a commitment; if it turns out to not be useful, you just remove it again. When it's easy enough, installing a package temporarily may become the easiest way to merely read about the package.

(Having lots of unnecessary packages is a form of clutter, and like all clutter makes your systems harder to manage. It may also expose you to more security issues, and it eats up more disk space, and so on.)

This implies that one of the things that a good package system should do is have as little done by install and removal scripts as possible. Scripts are an opportunity for people building packages to get things wrong, and it only takes a few mistakes to lose people's trust. Putting every routine operation in the package system itself means that only one set of people have to get it right, and they generally have a much deeper and broader exposure to the issues.

(Of course there are other things that competent package systems do to encourage experimentation, like automatic dependency resolution. But a good package system should have a way of removing a specific package and all packages that were only installed as dependencies; as far as someone experimenting with a package is concerned, they're all one thing.)