There are strong reasons to not run processes with full root privileges, and much work has been done to eliminate setuid executables from the distros.
One tool in the toolbox for more secure processes is capabilities(7), which was defined in the (now withdrawn) POSIX 1003.1e draft standard (http://wt.tuxomania.net/publications/posix.1e/download/Posix_1003.1e-990310.pdf.bz2). It provides a way to grant a process a finer-grained set of privileges rather than full root privileges.
The RPM packaging system has supported capabilities via the %caps file directive since release 4.7 (http://www.rpm.org/wiki/Releases/4.7.0#POSIX.1edraft15filecapabilities).
deb packages should similarly support a way to specify that capabilities be set on delivered files, to encourage the adoption of more secure practices on Debian systems.
Most daemons currently running as root do not require full root privileges, and would be more secure running at low privilege with specifically-defined capabilities as required. This would reduce the security vulnerability footprint of such processes and also ease security analysis of such processes by explicitly declaring security requirements via the capabilities set. Even if we do not tackle this approach with all processes today, encouraging this approach will lead to better security practices.
This is likely better done in Debian.
That said, dpkg-statoverride seems like a possible layer to extend. It is responsible for updating the owner and permission of files installed by packages, after all. Extending it to deal with capabilities, or for that matter POSIX ACLs and Linux extended attributes would make sense.
One could then extend debhelper to make its usage more packager-friendly, if a dh_statoverride module doesn't exit already.
Until we get that, most packages will do it like iputils-ping does (refer to its postinst script).