There isn't really anything in the code that suggests that the "mainline" mentioned is automatically deployed to production or deployed to anything at all. The article mentions CI/CD but that doesn't necessarily mean lights will go out if there are mistakes.

It all depends on what happens once code reaches mainline. For a desktop app, you might be a month from any production use of your code, and still use "CI/CD" where the CD is simply a nightly build, for example.

If you don't trust yourself, the domain expert on a piece of code, how do you trust someone else, who has less context, and their own work to do?

I think perhaps its a fair point for junior devs, who either don't have a good idea of how their changes might impact things broadly, or don't have the experience/developed aesthetic to know what is good/idiomatic/performant/code-smelly.

Have you never had a problem caught by a PR reviewer?

TL;DR - Two sets of eyes is better than one.

One of the most important aspects of code review culture isn't really mentioned in the post: requiring at least one additional approval on a PR ensures that at least 2 people are familiar with a piece of code. This helps increase the bus factor on the project and ensures that knowledge transfer and developer velocity can be maintained.

Additionally, the dialogue that occurs during code review can serve as additional documentation into why certain choices were made. I use the blame layer all of the time to try to better understand the context of a particular piece of code. Being able to read through the review for the PR that contained a line of code is often incredibly useful for being able to gain context.