There's a bit of truth in that. The file format is underdocumented. You've got to look everywhere to find snippets of information, and then there are these weird incompatibilities between versions (Service.Type bit me once, and either After or Wants simply didn't do what the scant information suggested). And it often starts a script or a dedicated tool, e.g. for backing up, or watching directories.
However, it's easier to deploy and keep track of your own services, sudo and chdir are built in, there's a watch dog, easy journaling. That's nothing to sneeze at.
I’ve written a handful of systemd units now and, while the simple cases are nice, anything more complicated is really hard to figure out by reading manpages or other official sources of documentation. And, additionally, I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself.
As far as the watchdog but things go there’s plenty of good enough solutions that don’t really on systemd: daemonize, DJB’s daemontools, etc.
I've written many systemd services, and other units. Some of which were quite complicated. I found the man pages extremely useful. Moreso than the manpages for sysvinit or upstart, when I used those systems.
However, it's easier to deploy and keep track of your own services, sudo and chdir are built in, there's a watch dog, easy journaling. That's nothing to sneeze at.