pragmatically, the only case I could see for doing this kind of flow is for a small project internal to a team that has no external entities that rely on it, so when things break it isn't borking shit for anyone else.
even then, its a borderline red flag.
no way do I trust myself to catch all edge cases, that's what code review is for.
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.
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.
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.