Personally, I'd prefer that packages get a default configuration and
services are never enabled on install. However, I get that some/many
people would prefer that debconf ask them enough questions to configure
a package and that the service be enabled by the end of the install.
For a (rare?) example I have had recently where I prefer services don't get
configured or enabled on install, consider build-depends required for testing.
I have a python library in Debian that build depends on slapd.
https://packages.debian.org/sid/python-tldapIt does this because it has tests that require slapd. The tests create a slapd database and run slapd on a non-standard port.
Unfortunately, when slapd gets installed it automatically configures a database (completely redundant) and starts a slapd instance on the default ldap port. This means you can't build my package in a schroot instance on a host that is already running slapd on the port (e.g. another build instance), because it will fail to install slapd.
It would be much better (for testing) if I could just install the slapd daemon without doing any of the automatic configuration.
As another example with the same package, any automatic configuration makes it harder to write scripts to automatically create a Debian install instance with slapd running for testing. I was working on this in my previous job. A change in the default configuration from testing to unstable broke my LDIF configuration changes (due to change in database backend). I was almost considering making step delete existing configuration after installing OS packages, so it could start from a clean/known state[1].
After being made redundant from my previous job, I am no longer working on this particular project. Still need to consider if I want to continue maintaining python-tldap or not as a result.
Notes:
[1] For the record the rpm packages were a lot worse then the Debian packages because they make assumptions on the default configuration, such as default DN, with no easy/obvious way of changing them.