We do this for several reasons:
- the fact that systemd is used to launch services is an implementation detail of snapd that we do not want to expose to snap developers. It is entirely possible that another mechanism could be used on different distributions or in the future, and we don’t want snap developers to have to deal with transitions or making the snap only usable on distros with systemd
- snaps can be installed on any number of systems with varying systemd versions. Exposing the unit files directly in the manner you describe could cause problems with snaps using units with newer systemd directives than the systemd on the system supports
- the systemd unit specification is extremely rich and flexible and exposing the entirety of the unit specification would allow snaps to influence the system and other snaps in unpredictable and undesirable ways that are counter to snapd’s design surrounding application isolation, reverts, dependencies, etc, etc
Because of the above, we do not plan to wrap the entire systemd unit specification (as you said, that would be unreasonable) and we are exposing a subset of the functionality. Do note that the subset of functionality is being expanded and reevaluated based on feedback from the field (eg, most recently timers and the thread you mentioned). Importantly, we want to expose needed functionality to developers in a manner that is consistent with snapd’s design principles and work everywhere in the cross-distribution ecosystem.