question for you: which would you have Debian developers do:
A: complain about historical issues in systemd that have largely been patched or addressed
B: complain about what systemd is like now
C: submit patches to systemd that fix outstanding bugs
D: submit patches to systemd that fix outstanding bugs and enable the non-initialization portions of systemd to work with other initialization systems like OpenRC
If you selected A or B, I think I can identify your problem. You seem to have a mind set more typical of Moronix or Microsoft in which the existence of software packages in the past is all those software packages will ever be in the future.
While that might be an accurate assumption to be made of proprietary software that is largely published and then only patched when something breaks, such models are generally not true to Open Source Software packages like KDE, the Linux Kernel, or Libre Office. Such software packages typically learn from coding mistakes in the past and new versions actively address various issues. E.G. a very popular point right now is how the lessons and resources from the Nepomuk development are being leveraged in the development of Nepomuk 2.0, aka Baloo. :: Another popular point in recent weeks can be found in the Open-Source X.org Radeon drivers starting to trade blows in OpenGL 3.x class rendering with the proprietary Catalyst driver set. :: Need I continue?
Now, I won't argue that the Gnome-Shell software is crapware; and you won't find me arguing against similar points on GTK in general. The Gnome-Shell and GTK developers are formed of infamous cliques that have done more to discourage modern developers than encourage them. Need I point out Valve's observations on the differences between QT and GTK development and the interaction with upstream developers... or in the case of GTK... the lack of interaction with upstream and existing developers.
I will argue that writing off systemd so quickly is a huge mistake. Do keep in mind that with less than half the development time (2010~2014) compared to Canonical's Upstart (2006~2014), the systemd initialization system alone managed to reach at least on-paper parity; if not in-practice parity; with the older software package. A large part of that rapid pace of comparative development was the loss of FOSS oriented developers who chafed at Canonical's CLA licensing modification. No, I'm not letting that one go, it is that big a deal: especially for Debian's stances on Software licensing.
Are such statements to be an understanding or equivalency as a statement that systemd is a perfect software solution? NO. Nobody here on Debian even got close to suggesting such a thing. The closest anybody here on these mailing lists got were statements that as of right now, systemd is better than SysVInit on Linux.
Adopting systemd does not, in any way shape, form, idea, concept, conclusion, thought, etc. etc. etc. prevent, pervert, divert, etc. etc. etc. the goal of a computationally stable, bug-free, and flexible operating system.
So do this, and other mailing lists a favor, knock off the Fear, Uncertainty, and Doubt. if you have the coding chops to actually comment on systemd's capabilities and features; or lack-thereof; at a code level rather than just at a Moronix Level, you'd probably be better off diving in and fixing bugs yourself.