(Note: satire. I use and love both Ubuntu and Arch.)
So, what makes the Debian package system superior? Having built multiple specs in the past, but not any debs, I'm curious. Given that you can often convert debs to RPMs and vice-versa, and can use the different package managers on either type of repository, it's not obvious where one has any specific benefit.
It's also undeniably true that there was a time when APT + dpkg blew Red Hat's "equivalent" tools out of the water, but that's not the case anymore.
One thing I like in particular about dnf/rpm is that I can install packages by using functions, so eg. telling yum to install perl(Net::DNS) will work and installs the perl-Net-DNS package. I'm not sure if apt can do this.
It took me days to grok how to make a proper debian package nearly a decade ago when I first did it - writing my first .spec file took an hour or so and now I can hammer most of them out in 15 minutes or less.
From the top of my head in the last few years I have (and you have also probably) used the following to get software: rpm/yum, deb/apt, pacman, ports, sysvr4(Solaris), ips, homebrew, pkgin, npm, gem, pip, hex, cpan and hmmm probably a few others.
They all do pretty much the same thing, one might have prettier progress bars or a better cli but we're just talking compressed tars with some metadata files.
Competition is good and all that, but how much innovation do we need to drive in package managers? We have lots of tools all doing the same thing with negligible advantages over their competitors and I don't see it as a positive.
Either use separate commands for different actions, or distinguish actions with arguments, but don't do both. E.g. apt-get install, apt list, apt-file update.
The software tools and packaging formats exist only to implement that. It's Policy and the comprehensiveness of the Debian archive (60k+ packages last time I checked, a year or so back), which make it bliss. You simply rarely have to go outside it, and you can configure a system as lean or rich, or anywhere in between, as you like.
What Policy states is that the package maintainer (not the user) must or must not do, including incorporating specified, requiring manpages (though that's not a release-critical bug), so that documentation is standardised. The fact that /usr/share/doc/ has every single package installed listed in it, and they don't include the installed version number in the directory names, as RH still does, means that you can use that directory to recover or rebuild from various packaging failures. (Why would you want to do that you ask? Same reason you'd want to have a doctor or hospital nearby if you had a broken leg -- it's not so much what you'd planned on, but it's damned convenient when you find yourself in that situation.)
Joey Hess and Martin Krafft (see the latter's The Debian System) both expanded on more elements of Debian packaging vs. other systems, particularly Red Hat / RPM.
http://www.worldcat.org/title/debian-system/oclc/640083534&r...
Why wouldn't you want the version numbers? That seems like something you would want when trying to rebuild a package database. Also, what do you do if you have two versions of something installed ?
2. You can reference content under /usr/share/doc/ without having to specify a goddamned version number that a) changes arbitrarily and b) is inconsistently specified every fucking time.
Version numbers are metadata, not directory name elements.
Changelogs, also required, give you the info if you desperately neeed it.