To put it clear, code review is not really for spotting bugs (even if it might do it), that is testing. Code review's purpose is mainly to keep project patterns, clean code, avoid local solutions.
To use a tool is useful, but it always worths the time and effort for a four eyes check to keep up good practices in the project. Even more senior programmers should let their code being subjected to a code review. The practices sometimes getting outdated or rethinked.
In Java I can recommend Adam Bien's works on rethinking old patterns. If the team is heterogenous (various workplace past + age), the regular code review is vital to avoid chaotic coding.
Just to mention an obvious reason why to spend time on code review: if the code is reviewed and becomes homogenous in practices, anybody can go on vacation without constant bugging about their solutions. Since the code is similar, others can actually deal with even the unfamiliar modules of the program in case of bugfixing. Also if somebody leaves from the project, there will be no modules with horrible solutions which nobody understands.
So when to stop? Never. The regular code review pays back in long run. Makes the code easier to maintain.