Spotting things the author missed is a low bar for code review. I believe the author assumes a context of high quality, well-tested code (e.g. "added a feature using an established pattern"). Unfortunately, for many teams code review is the only opportunity for improving code quality. If code quality is treated separately ("focus your efforts on activities that build trust, such as training, team discussions, or ensemble programming") then the importance of code review could be lessened.