The whole discipline Rachel writes about is clearly intended for mature, scaled operations where outages and inefficiencies are legitimately worth much more than the systems wizards to stop them. There’s a time and a place for “move fast and break things” and if that’s where you are, it’s probably not for you.
I don’t think you guys are saying different thing here.
The article in this case is describing a bunch of common processes/optimisations/features that we have learnt to be critical for effective and efficient running of software. The author does this because the audience she writes for is, as the previous comment puts it “mature, scaled operations where outages...” etc etc
