What the author gets at though I do think is important. I've seen a lot of programmers fall into what I'd call the bureaucracy trap. Bureaucracy is often very attractive to a certain type of engineering because it's essentially programming the behavior of other humans. Even if the tradeoff is that overall, an organization is less productive but more consistent that's a very attractive proposition to these engineers. Anything that makes other people behave predictably is welcome.
Of course humans are, at best, faulty in their rule adherence (there's a subreddit called "malicious compliance" for a reason). So engineers who assume that everyone will just follow the rules end up surprised when someone breaks them. Part of being a "hacker", at least in my definition, is being able to diagnose the actual dynamics of a system whether technical or social.
That doesn't mean I submit to the view that you should go around paranoid forsaking the tool of bureaucracy entirely. Nor do I think there's any social status conferred by openly breaking rules (a mistake that I see a lot of young hackers make). As XKCD (https://xkcd.com/1494/) might say, "That cool hack you just thought of is called fraud and we already know about it."
Rather I'd suggest that if you feel inclined to write formal rules or policies for the behavior of humans you should instead write guidelines, define principals, and create incentives. Focus your time on aligning everyone on the goal not the process to achieve it. Accept the things you can't control.