Mandatory code review means every single PR (Pull Request) must be approved by at least one person (sometimes rules are even stricter) for the author to merge it.
Mandatory code review is a usual process inside middle to big tech organizations. However, it's less common in small startups (less than 30 developers).

I think code review is necessary most of the time. Still, I'm against the mandatory aspect and want to share my point of view.

Context matters. Code review is mandatory: whatever the PR, whatever the number of people able to review the PR, whatever the criticality of the fix, whatever the hour of the day...

Lack of trust. Code review may avoid huge bugs, share vital information among developers, spread best practices...
Sadly, the mandatory aspect makes it almost valueless. Instead, can we trust someone enough to ask for reviews only if he thinks it's useful?
This time the PR review is more valuable: the author values specifically the reviewer's opinion. At the same time, you bring 2 things to the table: trust and a critical mind.

False sentiment of correctness. With a mandatory code review codebase, every PR has been thoroughly reviewed by at least one peer so the code quality should be high right? Having a peer review your code gives a false feeling of correctness.
Your code may have been approved by 1 or 10 people but it doesn't prevent it from bugs (human = not reliable) (of course it doesn't mean we shouldn't do them).

Even more interruptions. Each PR "ready for review" brings even more interruptions for 2 persons at least (the author and at least one reviewer, I'm not considering colleagues who receive notifications for code reviews but decide not to do it).
Many scenarios can occur but the most 2 common ones are:

• the author waits for someone to review its code and do something else
• a reviewer is kind and does the review quickly even if it means stopping what he's currently doing

Doing this in a mandatory fashion means you don't always value your time or the reviewer's.

Bigger PRs. We do not want to disturb one reviewer for a PR that modifies almost nothing.
So rather than doing this small PR, we end up doing big PRs to make the review worth it.

Doing things in a blocking way. PR reviews can be done a posteriori. Nothing prevents anyone from doing comments asking for modifications after the PR is merged.

Conclusion

Again, this optional code review doesn't mean "no code review at all" but "code review can be avoided". In practice, as most of the PRs modify impactful code, a code review is required (at the author's discretion).

Nonetheless, with optional code review you get:

• trust between developers. One can merge without approval so trust is needed
• no more relying on a colleague to spot a bug in PR: I own my code
• fewer interruptions. I value my time and the reviewer's. I ask for a review when it feels right
• no more huge PR with mixed code. PRs with reformatting, new unit-tests, readme... can be merged without interruption
• review can be done in an asynchronous fashion (meaning after being merged)