It is and it isn't. It does opinionated ways of doing things. But IMO what makes it so great is just how easy it is to opt out of the opinions you don't like. Facades are an excellent example of this: don't want to use them? Well, you don't have to (and IMO a really big app that may be a good choice - in a small app it likely won't matter and you might as well use them).
Anti-patterns are things like using a wrong data structure, using the wrong levels of abstractions, tightly coupling components so they are not composable, leaky interfaces, god objects doing too much
The strict definitions of many of these can be subjective at the edges, but they all objectively exist and cause fragility, instability, inflexibility and maintenance problems in the systems built from them.
Clean code is code that’s easy to read, has the right level of abstractions, uses the right data structures and has the minimal possible anti-patterns in them (ideally zero!) above.
Calling these things bogus is unfair, I grant they can be subjective in some places but they are prevalent in poorly designed systems especially by junior engineers.
Wikipedia page on anti-patterns: https://en.m.wikipedia.org/wiki/Category:Anti-patterns
There are project management anti patterns too https://en.m.wikipedia.org/wiki/Anti-pattern
Anti patterns are real. Clean code is real. If you cannot see that, I would suggest reading a lot more codebases from open source projects (pick medium and large codebases, not trivial programs) and after 10 or so you will see obvious structural and quality differences, as well as hundreds of anti patterns and examples of clean code.
I'll back this up with the example of Magento 1. It's a PHP e-commerce platform that has (at first glance) some of the cleanest code you'll ever see in PHP. It looked like the entire development team had come from a Java background. Every component was neatly divided into a PHP object with documented private and public methods. There was a clean MVC separation, with lots of shared behavior abstracted into "Helpers", and a Theme system handling the rendering of the front-end. I have no doubt that the authors of Magento prided themselves on how clean their code was. For them, having spent full-time careers structuring all the many features of their platform into these files, it probably did feel like a clean organization. And when I initially reviewed the code to evaluate using Magento, I also thought it was clean and was part of my choice to use it.
The problem was that when you take something as complex as a full-featured e-commerce system and modularize it so thoroughly, you end up with a literal 7000 classes, and it becomes impossible to figure out the sequence of execution of a single page request through that massive tangle. Is it "clean code" if I have to add debugging print statements to 57 source files to figure out the path of execution that renders a single page?
If I had to choose a circle of hell where I would edit Cyrus IMAP (the worst C code ever) for the rest of eternity, or edit Magento for the rest of eternity, I think I would actually choose Cyrus.
What is a "wrong data structure"? Is it wrong to do linear scans when hash access would be sufficient?
> ... using the wrong levels of abstractions
When is the abstraction level wrong? I can name you at least 10 projects that avoid so called anti-patterns by introducing unecessary abstractions. Is something really an anti-pattern if it's "solution" massively reduces your development velocity but now everything is nicely composable?
In my opinion, anti-patterns are either obvious (constantly using different names for the same thing) or totally subjective to the context (when to repeat yourself).
But maybe I'm not able to put myself into the shoes of novices and a lot of things seem obvious to me. Granted.
"Reasonably readable" is what I strive for nowadays, and a key aspect is that I no longer think there is an objective measure for it. It depends on the team/company you're in, and its important to keep in mind that the goal is to effectively communicate the program to them.