systemd that handles the old-style init scripts, using
systemd-sysv-generator is a generator that creates wrapper .service units for SysV init scripts in /etc/init.d/* at boot and when configuration of the system manager is reloaded. This will allow systemd(1) to support them similarly to native units.
LSB headers in SysV init scripts are interpreted, and the ordering specified in the header is turned into dependencies between the generated unit and other units. The LSB facilities "$remote_fs", "$network", "$named", "$portmap", "$time" are supported and will be turned into dependencies on specific native systemd targets. See systemd.special(5) for more details.
SysV runlevels have corresponding systemd targets (runlevel X.target). The wrapper unit that is generated will be wanted by those targets which correspond to runlevels for which the script is enabled.
systemd does not support SysV scripts as part of early boot, so all wrapper units are ordered after basic.target.
Essentially, the documentation states that
systemd generates unit files at startup for the services in
rc.d, and uses the LSB headers to determine when the services should run.
In Jessie and Stretch, LSB headers have been added to all old-style init scripts in
rc.d, so these can continue to work despite the switch to systemd. As for why this is the case: this answer suggests that the plan was to have sysvinit as a fallback in Debian, and most likely for compatibility reasons also.
That said, there are some contradictions between the documentation, and what users have observed to actually be true. This answer on Unix & Linux claims that the headers are not required at all for systemd to convert them, which would explain why systemd still used your script, despite you probably not writing a perfectly LSB-compliant header.
You will need to remove the init scripts as you would with the old init daemon in order to stop these services from running too. See also: disable init.d script in systemd on Unix & Linux.