It makes my job easier, AND it has no side effects? What IS this magical anti-pattern unicorn of which you speak?

I know of people who cite Singleton as an anti-pattern. There's folks what call Facade an anti-pattern.

I'm an old guy with a bunch of competing principles floating around in my noggin. An anti-pattern in one [language/paradigm/methodology] context may be fine in another.

Maybe, nah - probably...okay, to be honest, yes.

I would use it with care!

If it gets the job done on time, I will but surely put it on tech debt and get back to it once I have the proper solution and enough time.

I think the realistic question should be, "Is your design pattern actually an anti-pattern to quickly resolve an obvious issue, eventually causing a landslide of recurring issues in the long-run?"

I would, especially, apply this to AngularJS - which, whether it's admitted or not, was a complete failure and led to reinventing the wheel (Angular 2.x >), resulting in people abandoning that framework altogether because of its unreliable track record.

Not out of laziness, and definitely not because I don't understand the rules - I'll allow myself to break the rules in cases where I'm doing something that is unavoidably not going to fit well within the rules, and it's cleaner and easier to deal with later to write a rule-breaking solution, compared to the mess you'd have to create to stay strictly within the rules (if it's possible to accomplish at all). I won't let my pursuit of excellence be caged in by a set of arbitrary rules, and just toss my hands up accept that as a reason not to try to do better. Maybe the rules can be updated!

I personally believe best practices are for the median. As soon as we generalize/abstract we loose specificity which in term moves away from solving our problem to solving all problems.

Also a real pro can give you code that looks like the code of a beginner the only difference is that the pro knows what is happening inside and can reason about everything that is happening.

And the rule of 3 having a problem 3 times before abstraction is a good baseline.

It's a case by case basis ... what is the difference between premature optimization and abstracting into best practice patterns? In the end it's only time and amount data.

In awareness I am repeating myself over and over again :) anti pattern for what metric? a maintenance anti-pattern can be a performance pattern.

TL;DR; If you take the responsibility, communicate the why to the other stakeholders, they are okay with it, you think you know what you're doing and you can reason about it .... go for it.

Some time ago I will say "yes, sure" without hesitation. Now I'd be more careful. The thing with anti-patterns is that they are anti-patterns for a reason. Even if I don't see any negative sides now, it does not mean the won't surface in the future. I've seen it in the code too many times already. And such shortcuts are usually very difficult to untangle later.

If you include decreased maintainability in side effects, this seems an unlikely scenario... But if it happens, sure.