I consider myself part of the "hacker culture", and I'm sick and tired of this blind adherence to an operating system architecture from the 70s. AT&T UNIX is dead, and its ancestors only mimicked it chiefly for compatibility reasons (otherwise you'd have a rough time compiling any software that was written for UNIX on your new OS, and you'd never gain market traction).
I find very little value in the UNIX philosophy, and in fact I find that it adds a lot of needless overhead and puts MORE work on system administrators for no reason at all except that "we've been doing it that way since the 70s". I'm so tired of hearing this "criticism" of systemd.
More seriously though, if that's the best you can come up with -- that it's not "UNIXy enough" -- then systemd is well on its way to universal adoption. No serious maintainer of any distro except perhaps Slackware is going to take that argument seriously, because it's a strawman that should've died before many of us in the current incarnation of the hacker culture were even born. Now it's properly dying, and all the people who are stuck in the 70s are coming out of the woodwork to pitch a fit as their set-in-stone view of system architecture is rendered obsolete.
The UNIX philosophy had a time and a place, but just like any other design decision, it had major drawbacks. It worked well in the type of environment it was running in at the time, and continues to have some relevance today, but it is high time that we retire it. The new system architecture proposed by systemd may not be the best possible one, but I think it's a step forward from the old ways.
I would very broadly describe systemd's architecture as "service-based" -- you have one or more daemons that offer some kind of service over IPC, then wake up and process requests as they receive them from processes on the system. The kernel mediates the enforcement of access control, while the daemon(s) themselves mediate authentication (if required). It is a design that is pretty close to how we do web services in an enterprise environment.
We're getting away from "edit this file" and moving towards "call this service API" (or run a command that calls it for you, if you want to map the service architecture onto a model closer to UNIX). We are getting away from the rampant race conditions that come from file editing (look at the number of programs that try to touch/manage `/etc/fstab`, `/etc/resolv.conf`, etc. and end up stepping on one anothers' toes, and trying to parse comments like "#FooProgram edited this; leave it alone!" as interoperability hacks). When you have a daemon offering a service, you get parallelism safety by design: the program can just mutex the critical section, and make sure only its user and root have access to its (ultimately) file-based backend. And root has no business touching the backend directly.
"But what if there are bugs?" you ask. Well, if everything is in a bunch of text files, you can just edit those text files as a workaround, thus avoiding the actual problem. But it's much better to get the actual bug fixed in the program itself, so that you AND all other users do not have to trip over the same bug again and again. A text-based configuration architecture just encourages lazy sysadmin practices and hacks that make a system brittle, unportable, and difficult to maintain.
If you read this and you would still rather have the UNIX philosophy, just remember: even though the service-oriented system architecture is gaining the upper hand in terms of mindshare and adoption in most GNU/Linux distros these days, there is absolutely nothing stopping you and a group of friends from starting a new distro, or contributing to an existing one, that insists on remaining on the old UNIX design. It is physically impossible for anyone making any kind of policy decision in the free software community to force you to do or run anything. The only potential threat would be if a liberally-licensed software (e.g. BSD) development team decided to take their future contributions proprietary and shut down the code repos, thus stopping development (with all the existing bugs, etc remaining unfixed) unless you pay a license fee. That's a far greater threat than the existence of any free software could potentially pose.
Kind of ironic that the people who are the most emotionally uncontrollable about this whole systemd thing are the ones that are flocking in droves to BSD. I would actively encourage the OpenBSD, NetBSD and FreeBSD dev teams to seriously consider taking their future contributions proprietary, just to show these people how silly they're being. A much better solution long term is to continue using a GPL-based ecosystem (Linux, GNU userspace, etc.) and simply run the init system that you choose, and host forks of any packages that seem to have a "hard dependency" on systemd. Yeah, it's a lot of work, but there seem to be about a million of you who hate systemd, so if only 10 or 15 of you got motivated enough, we'd see "Old Hand Linux" or something get shipped 1.0 by Q4 2015, to the applause of 999,995 people over 50 and about 5 people under 50.
And not a single person would oppose you for releasing Old Hand Linux 1.0. It's completely your prerogative. Just as it is the prerogative of current distro maintainers to adopt (or not adopt) systemd. Start contributing, or get used to it.