> I explained, why systemd is a step in the wrong direction

I see a bunch of "I want X", but I don't see any "why"

>I want to use the tools I like

>I want to call a script that does that. A script which I can look at and see what it does

But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.

> They want to use standard tools to deal with the log.

I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating.

> They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.

I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.