Its also fairly niche and specific to developers that have a very developer-only mindset. Anyone who has spent time and designed systems with the bare-minimum feature sets needed to make operations supportable understands that most of the examples provided are very brittle, and purely opinion with little backing them. Its an overbroad generalization with a poorly thought through hypothesis that doesn't really match observations I've seen.
I've worked as a System Admin and System's Engineer over the years, most of the issues are solved when you follow good documentation practices.
If you aren't generating documentation in a way that others can read and understand, you simply aren't doing your job.
A proper IT Operations team understands this, the developers in general that I've met seem to think these rules don't apply to them, this includes the supervisors managing the business unit, and then they raise holy hell when SHTF like it wasn't a completely predictable outcome. There are exceptions but they are just that, 'exceptions'.
Average people should be able to read, and comprehend documentation needed for their position. If you can't do that, you aren't doing your job and deserve to be fired for misleading business about your skill set.
If you don't have good documentation for an existing system, you need to generate that first before you can really do anything new, its deferred maintenance that needs to be paid. Its impossible to put any reasonably accurate scope of work together if you have no documentation on a system, and only generalized requirements. Documentation is often a critical part of the initial requirement scope/process (before any work gets done).
You skip this phase, and you are tacitly approving a project that either will never complete, or will complete egregiously over budget.