Code review may take up to 20-30% of a developer's working time, including both reviewing code and waiting for reviews. This cost can be reduced by introducing a more structured code review process, which I will describe later in this article.
Ideally, you should analyze the trade-off between the time and effort spent on code review and the business value it provides, preferably using metrics, and decide whether the resulting improvements justify that cost. Each project must find its own acceptable balance. Code review is not a collection of strict yes-or-no practices. It is a spectrum of techniques that can be applied independently of each other.
That said, the short answer is almost always yes. Even a lightweight but structured review usually costs little and delivers significant value, which makes it reasonable to use in most projects. However, if code review turns into a "cargo cult", when reviews exist only formally, approvals happen without real discussion, and no actual issues are prevented, then you simply don't need peer-to-peer review in this form. In this situation, even basic self-review is likely to be more useful than a poorly executed peer-to-peer review.
If a code review process exposes communication issues or significantly slows down delivery, teams may be tempted to abandon it altogether. While this can bring short-term relief, the long-term outcome is usually negative. A more effective approach is to address the underlying problems, such as communication gaps or an unstructured review process, rather than removing code review entirely.