There are good reasons to prevent the auto-start behaviour. Having your own configuration ready for example. Preventing things from breaking when something is already listening on their default port. Preventing creation of the initial files in the wrong place.

You can find many more cases if you do more server automation. Most people don't need them, but it can be very useful. And no, it's got nothing to do with start on (re)boot.

> There are good reasons to prevent the auto-start behaviour. Having your own configuration ready for example.

Certainly. But in that case the daemon should also not start on reboot until configured.

After an install the system should be in the same state as after a reboot - there should not be an "in between state" after an install and before a reboot because such a state is not persistent.

There are tons of daemons that require that they be enabled before starting.

> And no, it's got nothing to do with start on (re)boot.

You are (I hope) confusing start as in attempt to run on reboot, and actually successfully run. Set the daemon to start on reboot, then check the config file and immediately quit since the file is not configured.

This is extremely common in debian installations.

There are also tons of deamons that feel that their defaults are good enough, and start right away.

But the thing in the article about "install" not meaning "run" is a red herring.

I agree. If the install is finished, then the system should be in its new normal condition, and that condition is either daemon-on or daemon-off. There is quite likely a real issue here worth fixing, but the fix is probably more nuanced than just daemon-off.

Why must they go hand in hand? What goes wrong if after installing a package the daemon is not started automatically, while the configuration is such that it will start on reboot?