Reverting the commit will often be cheaper to do than fixing the regression in a follow-on patch, but there'll undoubtedly be exceptions, which we'll deal with (and learn from) as a team.
(Emphasis my own)
As you've both pointed out, there are indeed instances where reverting a patch will be more expensive than simply fixing the regression in a follow-on patch. As with everything else in our profession, it's a judgement call, which require experience to make.
I certainly wasn't trying to introduce "if it's broke, revert it" as a rule either. We should be aspiring to have master always ready to be deployed. Demanding that it's always deployable would be setting ourselves up for failure.
Also is it a regression if the tests do not pick it up?
Yes. A regression isn't a tree in a forest.
We can't rely on tests to pick up regressions all the time. We don't have a dedicated QA team to defer to either. We're left with slowing down and being more deliberate in our functional review/sign off of patches. Taking a day a week to do a QA pass of the site also isn't out of the question.
–Sam