Well, for one thing, as Lennart discussed in his previous article in this series, the daemon manager cannot do all of the privilege separation and environment boxing for the application. So any sufficiently sophisticated daemon will have to do a substantial amount of the work it's already doing, or should be doing.
The work that systemd actually does for daemonizing is about ~30-50 lines of C code. Code which I already have to write because I need my applications to be portable.
Anyhow, I don't understand why people are arguing about changing the methodology of how systemd is daemonizing applications. My idea is merely to make the capabilities that systemd uses to manage services available from a shell-compatible environment, so all of that logic isn't hard coded in C. Inevitably the declarative configuration format systemd uses will rub some people the wrong way, and we'll be back to square zero in terms of dealing with ugly workarounds. Better to let people write workarounds so that they're less ugly, rather than forcing them into a rigid framework which presumes that we've reached the end of the road in terms of how services are managed, locking in current practice.
But this is all partly tongue in cheek. I have every intention of writing a shell like this, but I don't kid myself that it will ever find adoption.