systemd is emulating the system v init system only up to some point.
From the manual https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
systemd only stops running services. On traditional SysV a K link installed for shutdown was executed when going down regardless whether the service was started before or not. systemd is more strict here and does not stop service that weren't started in the first place.
If systemd doesn't know which PID is the main PID of a service, it will not be able to track its runtime, and hence a service exiting on its own will not make systemd consider it stopped. Use the Red Hat "pidfile: " syntax in the SysV script header comment block to let systemd know which PID file (and hence PID) belongs to your service. Note that systemd cannot know if a SysV service is one of the kind where the runtime is defined by a specific process or whether it is one where there is none, hence the requirement of explicit configuration of a PID file in order to make systemd track the process lifetime.
The main point is that if for instance the hadoop-yarn-resourcemanager dies, a puppet run will not restart the daemon, since the systemd still considers it running. This happens sometimes on debian8.
I like to propose to support systemd unit files in addition to the existing sysv init scripts.
And please do not bash systemd. It is a tremendous improvement of the Linux Boot process. We have to adapt.