The bottom line is things are done differently, so the actual preference is HOW you do something, not WHAT you are doing (that's why the whole DEB/RPM dispute is bogus).

1. I think apt-get dist-upgrade does exactly what he describes. In additions there is an (admittedly seldom used) selection mechanism using which you can specify exact packages to operate on, see dpkg --set-selections (and it's friends, get a and clear) plus apt-get dselect-upgrade

2. This is a default policy. rm -rf / will not tell you you're likely killing yourself either. You have --dry-run if you have doubts what the result will be.

3. sounds like --unpack

4. He doesn't like the debian/debhelper docs. If debian docs are too dry, Ubuntu has very nice packaging tutorials/guides which lack the 'BS' he disapproves of.

5. This has nothing to do with deb. It's just the way debhelpers work - preferring a multi-file setup to a singlefile one, I don't see how this is an objective technical disadvantage. You could unify the debian dir into a single file and build debs from that, nothing deb specific there.

6. dpkg-statoverride (or dh_suidregister). No idea what he's talking about when says it's difficult to make multi-binary releases from one source, all debhelpers do/handle this by default.

7. 3rd party apps. No bearing on deb, anyone can make a superfast deb-based thing too. H-A-M being slow because of all the apt-wrapping is Nokia's choice of not implementing any extra layer of indexing/caching (which is exactly what the 3rd party applications do).

8. debhelpers know about --prefix and dpkg itself has --instdir, it was (again) Nokia's choice to use special /opt handling instead.

That's it in short, off the top of my head. To reiterate, I don't really care either way, just that preferences of doing someting one way does not mean another way of doing the same thing is wrong.