handled as conffiles and kept around even if the package is removed
(unlike systemd unit files). Thus init scripts are still run[1] and
should behave sensibly.
For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors. So the init script still needs to
do something sensible (probably just do nothing).
I don't think this requirement is necessary to handle that case. There is already a separate, explicit requirement for init scripts to not fail for removed-but-not-purged packages a few paragraphs before, and Policy explicitly states init scripts should use ``test -f daemon || exit 0''.
[1]: For packages shipping native .service files for systemd, this might mean that for removed-but-not-purged packages suddenly the sysvinit script gets started? After all there is no longer a .service files to prefer over the sysvinit script...
At least for packages using debhelper that's not the case, as dh_installsystemd (and its predecessor dh_systemd_enable) mask the service on package removal.
Cheers, Oxan