Well, yes, but is there such nonsense to begin with? I.e. where does the original statement come form? Where is the canonical source claiming whatever is not a pattern, is an anti-pattern?

I have certainly worked in places where, for example, code consistency is rated so highly that writing bad code consistent with the existing codebase is considered preferable to writing good code. Quite literally pattern and anti-pattern.

Are you talking about formatting conventions or something else? Because if all you’re talking about is coding style, then yeah, it’s infinitely better to comply with the conventions of whatever your working on than do your own thing. For something as subjective as coding style, consistent vs inconsistent way more important than whether one style is used vs another one. That almost goes without saying.

No. I'm talking about things like endlessly copying horrifically monstrous multiple inheritance patterns, and painful single-threaded state machines instead of using threads to spin off work, and using shonky home-grown reference counting (that's thread-dangerous) instead of standard library smart pointers, and writing your own polymorphism instead of just using the inheritance that the language comes with, and leaving 80% of CPUs idle while trying to jam all the work into a single thread, and rewriting pieces of industry-standard libraries which then makes upgrading impossible, and writing horrifically heavy wrappers around simple DB access that turns modern DB interaction into sludge for the purpose of solving problems that the previous product had and the current product doesn't.

Take all that, and then insist that all new code do that as well. That's what I'm talking about.

The term pattern is not dependent on things being proven through formal processes and anti-patterns are not defined as things that are not patterns.

Anti-patterns can be patterns that have been proven through formal processes and the most successful of them tend to be.