Requiring enable/disable to be done from the inside requires every snap to implement those hooks. And implement them in a standard way so it is discoverable. I assert that most snaps will not, and will arrogantly assume that their daemons should be running, because less code and less configuration is good from the perspective of a snap author and provides a better user experience for most installations. However, some users need to manage their precious resources and need control beyond what the snap author provides, and at the moment the only control they have is to uninstall the snap (and destroy any related data). Laptops would be the main use case, where resources like RAM and power are tight and you often want to shut down services not related to the task at hand.
I don’t think the implementation should be complex. I particular, I don’t think any complex dependency management is needed or wanted (if you explicitly shut down the lxd daemons, you should expect anything relying on them to fail). I think the systemd implementation would be to dump a .override file in the right place. I don’t know about non-systemd environments.
Allowing snaps to enable/disable their own daemons or daemons of other snaps via an interface may be useful, but I think is a separate topic.
