Code reviews are one way to increase quality and consistency, reduce bugs, and lower effort too. When everyone is familiar with all the code, they know what they can reuse from elsewhere, they know what will be affected by their changes, and they feel comfortable working in any part of the code. And as a second pair of eyes, they may spot errors before they cause damage. Note: in order to gain all these benefits there's no need for the review to be performed by a more senior developer.
Consistency is very hard to enforce any other way. Say the team has a style preference about the way names are constructed: is it AddItem() or NewItem() or ItemAdd(), for example. Someone who writes a lot of code which all works fine but doesn't follow that style may be told to correct it, and may feel that's a big giant waste of time. (Most tools can make these sorts of changes trivially, so the response is more generally an emotional one about liking to be corrected or not liking feeling "wrong".)
Bugspotting is rarer, but it does happen that someone will say "this doesn't look [threadsafe, scalable, exception-safe]; did you test under [typical production conditions that don't occur on a dev machine]?" and a real bug is prevented. Generally this means the person has to start over and feels really humiliated for having made a rookie mistake.
The downside to code reviews is that they can get adversarial. It's hard for a reviewer not to think "what were you even thinking? Did you read our style guide? Did you even consider what production is like compared to your laptop?" and sometimes they say those things too. Making it a review gate where a senior person can pass or fail you intensifies the emotions. Developers often try to rebut corrections, saying that it's a matter of personal preference or that the reviewer is obsessed with an edge case that won't happen, or is just making up concerns to feel important or to humiliate the developer.
Now imagine instead that peers looked over each other's stuff all the time. Not as a gate that you can't get through without a gold star, but as a natural way of working. And they pointed things out to each other early, to save work and pain, not to cause it. That would be much better, right? In the same way that continuous integration and continuous testing made developers happier and code better compared to code-for-two-years-now-the-testing-can-begin, little reviews all the time - many times a week - will make developers happier and code better than one final you-thought-you-were-done-but-The-Nitpicker-is-here code reviews.
If you want to drop them entirely, you could. Plenty of code has been written and shipped without them. But it's a risk. Tests passing doesn't mean the code is readable and consistent. Not blowing up in production the first week doesn't mean it won't when you double your user numbers, or have 5 years of stuff in the database. You would be hard put to find any substitute for looking at the code to prevent those kinds of problems.