Devuan,
devuan.org, is a Debian-following Debian fork without systemd.
I think (my persional impression here) the issue with systemd is that it changed the way how smaller distributions dealt with certain components of the system.
No, it is the centralization (and lack of documentation) for the connected core system components. Horrible design known to be prone to failures. Buggy code, and refusal to acknowledge or fix bugs observed in their code. Compare to Bind, which was a Swiss cheese full of security holes, and is not that much better now.
(At one time, they even claimed that the Linux kernel boot parameters are not "kernel property", and stole the DEBUG parameter, making many kernels unbootable because early init system would output so much kernel log data that stuff would just grind to a halt. Their response? "Make the log buffer bigger; we're not going to do any changes on our end because we matter more than the kernel.")
Main problems include the added
single points of failure, unnecessary complexity and overloading of component purposes and communications channels, and in general, the complete disdain for the tried-and-known-working
Unix philosophy and modular approach that Linux distributions used to have. There is basically no bugfixes or patches outside the core group of developers, and the code quality is pretty horrible. Just download the sources and read them to make up your own mind, though.
Now, the main reason end users are not aware of these issues at all, is that whenever a systemd component (not the init service also called systemd, but one of the components maintained under the systemd umbrella, say PolKit, or the dbus daemons) fails, it looks to the end user as if it was the desktop environment or a specific application that failed.
It is also the main reason that these developers don't get pressured by those who pay their wages: they have chosen a way to avoid being responsible to end users, and therefore end users do not know –– have no way to know –– exactly who to blame or contact when such problems do occur. I'm a problem-solving junkie, and I dig deep and find these things out. It is very telling that core systemd developers believe that end users should not BE ABLE to contact upstream developers at all, and publicly advocate for such.
To do better, we should decouple init systems from desktop buses, privilege escalation/policy management, and so on, and implement them in a modular way.
Not only does that make it easier for projects to compete, but the most important side effect is that no longer could subsumed components "hide" their defects, as the modularity itself would force them to expose their issues. Similarly, the protocols and interconnections between currently subsumed components would have to be documented, and then they could be developed further, replacing the current non-externally-reviewed implementations with something more competitive.
You could say that my own attitude towards systemd components is similar to my attitude towards stuff manufactured in the Soviet Union: some of it works, some of it doesn't, but overall, the design and management of it all is utterly shit and completely cut off from the actual reality the end-users are dealing with, thanks to the barriers (stopping both criticisms and end-user complaints) these self-appointed developers have managed to set up. The only reason they got there is that they happen to have better social skills and money to pay for community management than those they replaced when their SystemD project started as an init system.
(The recurring discussions in various Debian mailing lists and bug reports is especially revealing. It is NOT the technical discussion you'd think: it is just chock full of evasion, social pressure, false claims, and whatnot. Basically a flamewar.)
Circling back to the original topic, none of that kind of community manipulation seems apparent at Mint. The agreement is very limited. Unless they do more of such, for example where the partner is someone else than the upstream software developer, then it is time to worry. For now, I'll just keep a lazy eye open on how things progress.