By the same logic, if an app written in C has a security issue due to a null pointer or buffer overflow, the problem is clearly the coder's lack of experience with C.

Actually yes, because it is possible to write correct C, and because they could have chosen other language less conducive to those pitfalls. But your analogy doesn't hold, because in case of shell, the situation is different: the pitfalls are easy to avoid, and for unix admin tasks, there is no compelling alternative to shell.

This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)

I’m sure the irony is not lost on you regarding the fact that systemd can not possibly run on an alternative platform, thus the situation you just ascribed is not “better” with systemd.

Sure. That wasn't in favor of systemd, though? I comfortably write code against the GNU userland and I use systemd where it crops up. Just not a big deal to me; if somebody wanted to use my stuff elsewhere I'd just say "pull requests welcome!". I found the inconsistency striking, that's all.

Checking for content of a variable before passing it to rm is a basic instinct that should be done in all shell scripts. The comment about --preserve-root is just a reminder that the problem of deleting / is very rare.