> The apple login bypass bug comes to mind.

I think you're talking about this "goto fail" bug?

https://teamscale.com/blog/en/news/blog/gotofail

> In practice, at my shop, we permit early returns for trivial things

Are you also writing C or similar? If so, then this rule is relevant.

In modern languages, there are language constructs to aid the cleanup on exit, such as using(resource) {} or try {} finally {} It really does depend on if these conveniences are available or not.

For the rest of us, the opposite of "no early return" is to choose early return only sometime - in cases where results in better code, e.g. shorter, less indented and unlikely to cause issues due to failure to cleanup on exit. And avoid it where it might be problematic. In other words, to taste.

> Kent Beck, Martin Fowler, and co-authors have argued in their refactoring books that nested conditionals may be harder to understand than a certain type of flatter structure using multiple exits predicated by guard clauses. Their 2009 book flatly states that "one exit point is really not a useful rule. Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t".

https://en.wikipedia.org/wiki/Structured_programming#Early_e...

this thinking is quite different to say, 25 years earlier than that, and IMHO the programming language constructs available play a big role.