The answer, as with everything in software development, is that it depends.
A god method with 100 optional params that is usually bad practice. But a common pattern is to allow for an options object to be passed, and that object may contain 0-n supported parameters. This pattern is used everywhere, see graphql as a widely used library that is based on this.
All jokes aside, I like the way this article breaks down types of optimizations. Especially the forth, as that tends to be the answer on occasion.
I’ve never heard of WET, but that is exactly the process I preach to my team. Refactor only once the same code block is used 3+ times as that tends to define a method that is a utility and not business logic specific.
This method has worked well in the past.
Set up 1on1s with your team. Weekly or biweekly, depending on level and team size.
The other, most important task is to delegate. Learn how to identify when you should step back and let your team solve a problem. Lead from the front, but start to learn how to effectively delegate. This is the thing I’ve seen many others struggle with as they get promoted.
You are no longer a dev. You are now your team. Your future success depends on not only your own performance, but your whole team.
Simple answer, unit tests.