I can address a couple I believe:
This is somewhat confusing to me. But I believe shows an utter lack of understand of apt (from the man page):
Edit: Oh, I see - he only wants to do a "apt-get upgrade" of certain packages. I guess I've never run into this problem.

This is actually a matter of preference. Having dpkg behave in this way allows me to then do "apt-get -f install" to automatically download and grab the dependencies for that package, and then properly install all of them. No dependency hell (meaning tracking them down myself, or yum installing them one by one), so to speak. What is the equivalent of this in rpm?

His #3 about scripts is an interesting perspective. But it can be both good and bad. This is entirely based on the packager and whether he did a good job or not: But a *lot* of proper uninstallation can be put into prerm scripts and thus, if you don't run them, would leave your system in a very flakey state. If there's an error in the script, then it's obviously a problem, but skipping the script altogether may not be the best answer (although the option *should* probably be there..) because there is no telling what the install scripts could have modified that the remove scripts should be fixing without going into the script and reading it.

As far as his Build documentation (#4), that's entirely perspective. I have never had a problem finding the necessary how-to's to building a deb file properly or the proper formatting of the files.

The Build files (#5), again, never had a problem with this. And the nice thing about the debian/rules file is you can manually edit the exact steps needed to compile a piece of software: in case you get something that is written using a strange system other than cmake/qmake/automake/etc. I personally like having separate files, it's cleaner and easier to read, than a single, long, file to accomplish the same thing.

Somebody else will need to address 6.. I don't understand how RPM can magically allow a user to suid root a binary that debian can't. This looks like something that should be taken care of in a postinst type script and can only be done as root... and the .deb takes and packages up the files with the permissions that they were given when you build the deb package - so if you suid the binary as root, build the deb, and then install it - it will come out suid. I don't understand what he's getting at.

#7 - Speed. Um... ok? There's helpers for RPM.. and there's helpers for Debian... so... who cares?

#8 - Tries to simplify a complex problem. You can't just dump your binary into /opt/whatever-you-want because /opt is not in the $PATH of the users. So, in addition to redefining the prefix to install to (which, by the way, is perfectly possible by editing the debian/rules file to pass whatever prefix options you want), you also need to symlink the proper binaries to the rootfs. Until and unless there is an official and standardized directory structure to place executable binaries: such as /opt/bin and not /opt/package_name or /opt/usr/bin or /opt/MyMommyThinksImSpeshul... etc. Currently I haven't found anywhere that says "This is the exact opt structure your app should look like" - so what we end up with is 30 different applications optified to 30 different sub directories and they can't all be added to the users $PATH unless every application is written to modify that variable every time. I don't see any benefit to using RPM's __prefix over just add --prefix or CMAKE's prefix commands to debian/rules.

#9 - bells and whistles: Yay? I'm sure dpkg/apt have a few RPM don't as well.. what's important here is the basic structure of package installation and dependency management.

At this point.. in those specific developments.. it doesn't matter if you have DPKG or RPM.

The main thing that matters, as has been repeated many, many, times - is the actual structure of the filesystem and OS. I personally have never liked SuSE, Mandrake's, or Red Hat's structure. I also have had no end of trouble using Yast or URPMI and up2date.

However, I've never had any complaints with YUM. So I don't care if either YUM or APT-RPM are used in the new system - they both work fine for me. As long as the OS structure makes sense.