Because it actually catches issues.

Your unit tests are never good enough. Your integration tests won't match your production environment. Your canaries only test the happy path. If your goal is full CI/CD, some changes will make it through that will impact at least a subset of your customers in production without being caught.

A good code review process utilizes a larger portion of the team's understanding of a system, not just your own, to help catch some of these issues. This understanding could be system, product, or inter-team dependencies that you will never fully codify into an automated process.

It also socializes best practices, help folks learn new patterns and improve as software engineers.

There are a lot of qualitative reasons: it helps spread knowledge of changes in the code, it helps maintain a consistent style, shares knowledge, etc.

However when it comes to quality assurance and correctness (if these terms collectively mean, preventing defects) then there's little evidence that it is an effective practice [0]. If the changes proposed are less than a couple hundred lines of difference and the reviewer is only reading one every couple of hours there's small but significant chance that they might catch an error. Humans are simply bad at this task.

[0] https://sail.cs.queensu.ca/data/pdfs/EMSE_AnEmpiricalStudyOf...

Why does the tech industry still rely on CR for this purpose? Probably because running empirical studies is time consuming and expensive. Instead we rely on the intuitions, experiences, and feelings of people, advice we get from others, etc.

Review can also effect maintainability; the code should ideally be parseable by other people on the team with little context of the specific project. And it should ideally spread knowledge of the code to at least one other person.

Because when done in a team where people want to work together and do not have incentives discouraging that it is a really good tool for spreading knowledge and improving maintainability. So far I have only once worked at a place where the review culture was bad and that was due to issues much bigger than the code reviews (specifically a culture where a different team wrote code for another team to maintain, encouraging shoveling shit code over the fence).

By CR do you mean meetings where everyone talks about the code? Or a github-style pull-request? I personally find meetings where we talk about a pull-request to be a poor use of time. I want to have time to read, reread, and interact with the code.

Shared understanding + bus factor. Everything else is marginal.