I disagree. My initial reaction was to lament the fact that BusyBox syslogd has lost the ability to be passed its socket as an open file descriptor. One may debate whether systemd's mechanism or UCSPI-UNIX (extended to datagram sockets) is the better way to pass such descriptors along. But it now has no mechanism. BusyBox syslogd is now less than it was.
Also, for busybox syslogd, it does not matter at all whether you can hold its socket. syslog isn't a reliable mechanism anyway, and busybox is light enough that the non-ready period is really short.
So, on the technical side, the impact is quite minimal. On the political side, however, it looks like Denys made a splash, and I'm not going to complain about it. :)
The significant technical aspect is, as I mentioned, that now there's no mechanism to pass an already-open socket to the daemon. nosh has several service bundles supplied out of the box for providing syslog service. They provide the various combinations of two different syslog tools over /run/log, UDP port 514, and /run/systemd/journal/syslog. Each operates in the UCSPI(-like) way, opening the datagram socket specific to the service being run, dropping privileges (in the syslog-read case), and then invoking the daemon program. All sorts of fairly obvious (to those familiar with the daemontools way of doing things) consequences ensue, like separated streams for local clients and remote clients, and control of whether and whose remote client service is provided that is as straightforward as taking the individual services up and down.
Rainer Gerhards rsyslogd and the nosh toolset's own syslog-read both support this. The BusyBox syslogd used to be usable in this way, as well. udp-socket-listen and local-datagram-socket-listen have a --systemd-compatibility option that would have interoperated quite happily with the BusyBox code as it was.
But thanks to BusyBox syslogd now being less than it was before, the systemd compatibility won't work and there's no mechanism for this in BusyBox syslogd. In taking a sideswipe at systemd people, Denys Vlasenko has made BusyBox less operable with other systems that are not systemd. That's a shame, in my view.
I don't develop embedded systems, but systemd is actually popular in that space because of its watchdog capabilities and its inclusion in projects like GenIVI and Tizen.
More detail is in this post from an embedded systems developer here: http://www.phoronix.com/forums/forum/phoronix/latest-phoroni...
The political significance is quite high, and I have to say I feel that this move, though perhaps a bit childish, is a valid signal to express grievances with the absolutist attitudes of the systemd developers. Plus let's be honest here, they aren't the pinnacles of mature behavior either. I think this is the first time a major project has done a statement like this against systemd. I would expect more to follow their example.
I of course summarized my issues in "Structural and semantic deficiencies in the systemd architecture for real-world service management" [1] and hope to see systemd go the way of devfsd and HAL.
[1] http://blog.darknedgy.net/technology/2015/10/11/0/