I have, however:
-Had a VP who insisted I styled the unsubscribe link to our paid subscriptions 10px font and deliberately violate WCAG contrast guidelines (not that he could be bothered to learn or listen on what that means, he just wanted it invisible)
-Had a founder ask me to deliberately bury an app settings button in the primary menu three layers deep to (aspire to) throw folks off the trail of account deletion
And I could go on like this.
I work for a company that historically avoided dark patterns since I joined. Whenever someone suggested a dark pattern, it would get called out and we would figure out a different solution, it was quite refreshing.
Last summer, one of our designers started heavily and repeatedly pushing certain dark patterns to our product team. I'm not sure the product team knew that these were dark patterns, and would get approval. When it came time for the developers to review these changes or additions, we pushed back like we normally would. But since there was no clear definition of "dark pattern" or enforced policy that we would avoid them as a brand/company, we were told that these were not dark patterns despite definitely being such and effectively forced to implement them. I didn't touch that code, and half of the team also refused to take on this work.
I've noticed this has become another feud between product/design/ux and engineering. I would think that UX experts would avoid dark patterns because they decrease the quality of the experience, but when the business and product become involved there are competing interests.
Without giving away too much detail I’d ask if that designer is a one person or very small department? That would be my guess. It makes these arguments a lot easier to win if you have a mature design practice with good leadership who can say “What biz/sales/product are asking for is not feasible as it violates our established criteria for dark patterns”.
This is, of course, toothless in small or medium sized orgs that only maybe have a few floating designers, for example.
We don't really have established criteria, we're a smaller org and typically it's been the developers that have resisted implementing any dark patterns while offering alternatives and product has historically been supportive of this.
And yeah since we're a small org, we have a small design team with just a few floating designers. The example I mentioned was with just one in particular and the only one my team really works with.
I judge devs that way, too. The root cause may be management, but nobody has a gun to any dev's head forcing them to write crappy programs. If management doesn't allow for making good products, then why are you working there?
In the end, we are responsible for the work we produce. If we produce bad work, we deserve the criticism for it regardless of whether or not it was because of management failures.