I'm not sure what the OP 'mergy' intended, but I'd guess that the intended reason had to do with better ecosystem curation. Under the hood, my understanding is that .rpm is marginally inferior to .dpkg, but not remarkably so. E.g. using cpio instead of gz as the format basis. So by elimination, the only reason to prefer .rpm would be the rpms, if you follow.

As a longtime Fedora user and a recent emigre (post-Snowden) to OpenSuSE, I agree that there is much to love about the selection of RPMs available, especially under Fedora. Although I'm sticking with suse for the lightning-fast zypper (still noticably faster than yum or even its slated nextgen replacement dnf!) and well-thought-out snapper utilities. But that is OT.

Mostly it's a matter of picking your poison. dpkg allows some things that RPM doesn't, and vice-versa. dpkg does have some nice features (well, features I can't remember, except for I went "Ooo, I want rpm to have that" when I saw it)

One thing that dpkg has that really annoys the hell out of me is allowing for user input during the transaction. It makes unattended upgrades impossible

In general Debian/Ubuntu packages do not prompt the user with debconf questions these days, although there are occasional leftovers in old packages if you upgrade via a terminal with apt-get update.

You can define an environment variable, DEBIAN_FRONTEND=noninteractive, to force even the worst-behaved packages to never ask a question.

You can set those configurations, certainly, but it's up to the package maintainer to actually respect them. At my previous company, I occasionally ran into packages that insisted on trying to read from the terminal, even when installed noninteractively, with all configuration flags set to noninteractive. I can understand the potential appeal for a lone individual working with a small number of hand-maintained systems, but when working with a large cluster, interaction during package operations is just a horrible misfeature.