Short answer: it's OK.
/lib/systemd/system/lvm2.service is created as a symbolic link to /dev/null by the lvm2 Debian package, causing the service to be permanently masked, because the job of the SysVinit-style /etc/init.d/lvm2 start-up script is actually split into multiple native systemd units.
lvm2.service needs to exist, though, because otherwise the SysVinit compatibility logic would automatically create a systemd unit that would just run that script. Since a systemd-native /lib/systemd/system/lvm2.service exists, that won't happen - but because all the actual work is done by instances of lvm2-pvscan@.service and the lvm2-monitor.service, the only job of unit lvm2.service is to mask out the redundant SysVinit-style startup script.
Also, you're correct that LVM can be used on a Debian system disk, as long as /boot is placed into a traditional non-LVM partition that the system firmware can understand - as GRUB is using the services of the system firmware to access files from that filesystem.
(Yes, modern versions of GRUB do include the capacity to read filesystems on LVM. Debian 9's version of GRUB even includes the lvm.mod GRUB module. But the problem is mostly that the Debian Installer cannot yet set it up reliably - or could not at the time of Debian 9 release. I would guess it's probably mostly about getting the installer to "understand" the new possibilities when having /boot inside LVM, and getting it to warn the user about configurations that won't work.)