This is less DevOps and more poor software engineering practices (code reviews, unit testing, paying off your technical debt through refactoring/removing old code, etc), although properly managing and instrumenting deploys might have stemmed the bleeding and kept losses manageable.
It's good though; poor decisions must have a cost. The only way to enforce good engineering practices that are human time intensive is for there to be a cost not to.
I think at it's core it is right in the guts of DevOps. The "flag" that protects dead code is dev, and the unforeseen deployment scenario is ops. With a DevOps mindset you need to think of both. I think it is a stellar example of what can go wrong if you don't consider both the dev and the ops aspects.
It's good though; poor decisions must have a cost. The only way to enforce good engineering practices that are human time intensive is for there to be a cost not to.