So is this all just people acting on some philosophical principle, rather than picking the best tool to complete the job they want?
No. That's just how it's presented to minimize the functional shortcomings and design flaws on which many people, myself included, base the decision not to use systemd for practical reasons.
* It's in "rapid development.": Presumably, this is thrown out by proponents to counter that the crufty old init systems are stagnant and old. To anyone responsible for maintaining production servers, this is likely a huge red flag. It's not for dramatic reasons that the "rapid development" version of Debian is called "unstable," for instance. I don't want to provision 3 servers with the same Linux distro over a 3 week period and find that they have 3 different versions of systemd on them. Add to that the fact that the devs behind the project don't have the best reputation for stable, well-functioning software, and you don't have an ad hominem, as much as the systemd salesmen might try to claim so; you have people who don't want another pulseaudio debacle that lives in the startup process now.
* SysV init/initd/upstart/etc.. all suck: No argument here, but using this dodge to handwave away the design flaws of systemd feels like the Congress Fallacy.
i.e. "Something must be done to improve the init system." "Adopting systemd is something, therefore adopting systemd must be done." It completely ignores the fact that systemd sucks, too, and it sucks in new, exciting, and unpredictable ways, without actually solving any of the *actual* problems with the old way of doing things (changing the format are just changing one arcane incantation for another) and just adding "solutions" hoping they find a problem to go with.
* "My skill set/use case/worldview doesn't see X as a problem, so X isn't a problem": The devs are just as (or more) guilty of this even than the proponents are. Binary logs, everyone's favorite dipshit stick in the whole mess falls here. The problem isn't that it's "like Windows" (it's not), and not that those who dislike it are "afraid of change" (we're not). The problem is that a system log facility that only works when nothing goes wrong is tits-on-a-bull useless. System compromised and the intruder corrupts the log? Oh, that's a feature, because otherwise he could edit the log and feed you misinformation -- that kind of reasoning suggests that the developers understand neither security (if it's trivial for the admin to unpack the log, it's trivial for the intruder - binary storage != encryption) nor system administration. It doesn't help that you run the same risk if a UPS or thermal sensor fails and the server powers down ungracefully -- the kind of situation where you'd damn sure WANT access to your log files. It seems none of the devs have ever worked on the other side of the switch.
* "I AM TRAPPER KEEPER": At best, systemd's ever-expanding feeping creaturism demonstrates an especially solipsistic "NIH" mindset. More cynically, I'm led to to wonder if the thought process isn't more along the lines of the devs being sloppy or incompetent and unable to figure out a "neat" way to work alongside the rest of the system, so they just roll their own network stack, DHCP client, and even console into what was, ostensibly, an init replacement. Either way, I'm not willing to risk my systems to RedHat's whim nor Lennart&Co's track record.
There's just a few of my personal, completely pragmatic reasons to eschew systemd and any distribution that includes it by default - the latter not out of principle or dogma, but because there's no telling when they'll let their package manager require systemd for some software I'll actually need.(Ian's GR tried to address that possibility for Debian, and had it passed, I would be transitioning to Debian rather than FreeBSD).