Really? How can systemd be sure that Apache has started completely and is ready to serve pages?
The answer is...exactly the same way every init script is "sure" that a service has started. It checks for the running instance, it checks PID, etc. But, unless it actually connects to the correct IP and port from a permitted IP and retrieves a web page that says something like "yeah, I'm running", systemd doesn't know.
I written service-monitoring scripts, and what systemd does isn't it, and is fundamentally no different from what is done by current init scripts. The difference is the current init scripts won't kill and restart Apache because they "think" something has gone wrong.
And that shows how little you know about init.
Init KNOWS/strong. when processes exit. In fact, the Unix process model is that there is ALWAYS a parent process (except for the first process, but that's usually treated as a special case in the kernel is the parent). In other words, it doesn't matter how you start programs, in the end, init, the first process, is the parent of all of them.
And parent processes get SIGCHLD whenever a child they spawned dies. In fact, init is the parent to all of them, so it knows exactly when a daemon dies. Especially if it spawned them.
Heck, init is called upon when there is no process waiting on a process because otherwise a dead process is still "alive" and has state the kernel is tracking (the exit code, namely). Init reaps such processes. (And perhaps you're familiar with "zombie process"? That's an unreaped process where the parent hasn't yet retrieved the exit code).
So no, systemd doesn't rely on PID files. It does note the PID of the service it started, and when the kernel notifies it that the process died, it can check to see what it should do - restart, log, alert, etc.
In fact, PID files can be trouble because PIDs are reused. Hopefully it takes a while and someone notices, but maybe not.
So something like Apache? systemd would know when it dies and how to restart it. Heck, it even knows if it fails too quickly, it can suspend restarting for a few minutes!
Oh, wait, did you not notice that even regular SysVInit has that feature? Because guess what - SysVInit is a daemon manager as well! You normally know it to run "getty", but that's just another daemon. When getty dies, init restarts it so you can get your login prompt back. If something nasty happens and getty dies too often, init suspends restarting it. (And given init may spawn 5-6 instances of getty - it doesn't use PID files to track them, but its internal database it created from /etc/inittab to track which instance of getty belongs to which line).
Init is far better at managing processes than trying to manage PID files manually in scripts. Especially if the PID files get desynced and you're having to ps your way to figuring out how to get the daemon killed and restarted properly.
Init is a process manager, in the end. Sure it also handles starting up, shutting down and going between runlevels, but that's secondary to the fact that the kernel uses init for various functions in order to maintain the Unix way, and that is every process has a parent, and in the end, that parent can be init.