Devuan Jessie beta released

This implies that systemd is being opposed for not being sysvinit.

There's nothing wrong with System-V init. It was a great idea in its time, which was the 1980s, and was a huge improvement on what came before. The issue with System-V init today is that it is now 30+ years old, and during these three decades the problem it was designed to solve has changed considerably. System-V init has patently failed to evolve to address these changes in the problem space, and is therefore ripe for replacement by something that was written to work well in the 2010s (and hopefully beyond). By broad consensus this seems to be systemd.

Regardless of how one rates sysvinit, systemd is worse: things worked before systemd, after systemd they do not.

I don't think this is in fact as black and white as you make it out to be. Lots of things work better now than they used to. (Remember how people used to have to put random “sleep” commands into their init scripts to mitigate race conditions, which are now being solved by actual infrastructure.) Things that actually don't work tend to get fixed as bugs. After a number of years of bugfixing there are in fact very few things left that used to work before but now don't, while there are many things that work more consistently or are in fact convenient to do when, before, they were a huge hassle to implement.

This is on top of a number of other advantages of systemd, including (but not limited to):

• The various components of systemd actually follow a common design, unlike the traditional setup (System-V init and init scripts, inetd, cron, …), which was assembled out of random pieces from a variety of unrelated sources with no overarching idea of a cohesive design.
• Systemd has done a lot to unify “basic plumbing” between Linux distributions, leaving distributions' maintainers free to concentrate on other areas that provide value to users, and making it easier for upstream developers to include systemd configuration files that are more likely to work across a large variety of Linux distributions, thereby reducing distribution maintainers' work even further.
• All systemd configuration files “smell” the same, while in the traditional setup no two configuration files have the same format (/etc/inittab vs. /etc/fstab vs. /etc/inetd.conf vs. /etc/crontab vs. …). This is on top of init scripts being essentially free-form shell scripts that consist of 90% boilerplate but are still specific to individual Linux distributions. This makes systemd-based Linux systems a lot easier to learn, teach, understand, maintain, and customise than Linux systems following the traditional approach. (I used to make a living teaching people Linux system administration, and believe me I never met anyone in my classes who didn't like the idea of making Linux system administration easier to learn and understand.)
• Continuing from the previous point, all the various components of the traditional setup use different ways of starting processes (e.g., init vs. init scripts vs. cron vs. at vs. inetd). These subprocesses can have wildly different setups (environment, working directory, capabilities, I/O setup, …) depending on which service started them, and a system administrator must be aware of these differences and take them into account when configuring, e.g., cron jobs vs. at jobs. With systemd, the same mechanism is used in every case, which not only makes a subprocess's environment, resource limits, security attributes, … more straightforward to configure but also leads to less code to debug and hence fewer bugs.
• Systemd removes the necessity for system services started from init scripts to go through an elaborate song-and-dance routine in order to dissociate themselves from the script that started them and be adopted by the init process. In fact, systemd has a much clearer picture of which services are running and which aren't and is able to restart services that fail, which is something that System-V init ignores completely – a system administrator has to add their own infrastructure, not usually provided by default by Linux distributions, simply to ensure that a service once started by System-V init actually remains up and running.
• Systemd is designed to make systems more maintainable by enforcing a clear separation between configuration provided by the distribution and configuration provided by the local administrator. This makes it a lot easier to identify what was in fact changed locally, and to carry local setup across distribution upgrades. The traditional setup has nothing to offer in this regard. For example, if you want to change the way your system starts a service like Apache, then in the traditional setup you are reduced to figuring out the (distribution-specific) Apache init script and customising it to suit your requirements by hacking shell code, even for basically very simple things like running several independent copies of Apache on the same system. These customisations must then be carefully preserved against the case that the distribution ever decides to upgrade Apache (and its init script) because there is only one place on the system where init scripts can go and it belongs to the distribution.

In general, the tradeoff between the traditional setup and systemd tends to come out in systemd's favour, which is the reason why so many distributions decided to base themselves on systemd rather than the traditional setup (they didn't do it because they love Lennart Poettering so much or because Red Hat was bribing them, after all – they did it because they evaluated systemd and liked what they saw). It is of course possible to deny all of this, but doing so is likely to make the deniers look progressively more ridiculous as time marches on.

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify

[Install]
WantedBy=multi-user.target
Alias=sshd.service

[Unit]
Description=A silly example of overriding a directive