What's the point in Code Reviews?

1. Code Quality Assurance - If something isn't obvious or clear in the code to a reviewer, this can be pointed out as a weak spot in readability and addressed. Or a place where the complexity may be higher than needed, and a simpler approach could be taken.
2. Wording - Developers think naming things is hard, so having someone else point out a different way to word something user facing, or a different way to name a variable is valuable.
3. Code culture - Most things are handled by linting, but some parts of how the code are written are stylistic and enforced socially.
4. Feature understanding - On a product where things move fast. I may be working on Feature A and not really following what is going on with Feature B. But during a code review I get a chance to learn more about Feature B, it's goal, and implementation.
5. Feature Quality - This is the first time someone other than the person that wrote the code will run it and try it out. Did it work? Did they find a bug? Is it less intuitive than expected? Lots of quality improvement occur through this process.
6. Security - If the reviewer is knowledgeable in security best practices, they may be able to find and point out issues early before the code is merged.
7. Malicious Intent - This is insanely rare, I've personally never dealt with it, but I imagine if I was in charge of code reviewing submissions to a major Linux repo, there would likely be some shady government agents from a number of different countries trying to sneak in back doors or exploitable code for their own uses. Or if it's someone's last week at a job and they want to commit an act of little bobby tables on their way out. If a code review process is in place, there's no real point in attempting something obviously malicious on your way out.
8. Finding points to automate - This is often the case on new projects or new teams, you will find some point of value that the team cares about (for example, alphabetizing imports in a file), then instead of someone trying to enforce this pattern on each code review, you use a tool to automate it (like a linting plugin).
9. Preventing squished feet - If two people are working on the same part of the code base it can be easy to "step on each other's toes". Code reviews give an opportunity to see when someone else is working in a part of the code that you were about to start in, so you can fork off of their branch, or work on something else until that code settles down. It also lets you better understand the changes that are going in, so if you already started work, you'll be able to more easily deal with merge conflicts as they arise, if delaying the work isn't an option.
10. Discussion - Sometimes you are dealing with a new way of organizing or abstracting a part of the project. Discussions around different approaches are important and depending on the context, the best place to have those discussion may be in the code review itself. Many times I've seen a developer not super confident in what the best approach is, and they'll specifically call out that they want input, commenting on their own PR.
11. Documentation - Sometimes a new pattern emerges and having a new set of eyes on it helps to make it more obvious that it needs better documented, either as comment blocks, or in README's.
12. Testing - All testing tools are garbage. No one likes testing, not even sociapaths. But they really do offer a lot of value. But it's also easy to do them poorly. And it's easy to want to skip them. So knowing that someone else will be reviewing the code will help to keep you honest and to take the appropriate amount of time to write good tests.