It gets used whenever someone doesn't like something for a reason of personal taste and people who don't really know (like your boss) immediate fixate on it and think "well, we must do that then and why is the other guy (you) suggesting that it doesn't apply in this case? Best practises ALWAYS apply surely? I will have a quiet word with him about standards..."
IOW it's a short circuit to not justifying something. If something is best practise you can explain why it suits the current situation and if you can't explain why then it doesn't matter.
Well, sure, but since every decision has tradeoffs, sometimes when arguing for or against a decision, it's easy for managers to side with the person they have more rapport with, who may or may not be correct, rather than decide on technical merits alone.
So, in some cases, it's more beneficial for the company to adopt a "best" practice, than to have engineers engage in arduous discussions, which can cause resentment and further problems within the team.
Needless to say, it's a delicate balance, which is why I wouldn't want to be a manager. :)
That said...
> I will always distrust engineers who justify decisions by saying “it’s best practice”. No engineering decision is “best practice” in all contexts! You have to make the right decision for the specific problem you’re facing.
There are indeed general best practices that are applicable to most, if not all, situations. E.g. version control and testing (arguably even the testing approach) are practices that every competent developer would agree are pretty much requirements.
Context does matter, but within specific contexts there are practices that can be generally considered "best", because applying them delivers more value than not, and their drawbacks are manageable.
For example, after a certain team size, implementing a CI pipeline is a best practice. Yes, it takes time and effort to implement and maintain, but the benefits far outweigh the drawbacks. After a certain scale, implementing a robust and efficient infrastructure management and deployment solution is pretty much a requirement. Relying on ClickOps to provision infrastructure, and deploying with shell scripts over SSH, while technically "simple", can only get you so far. And so on.
These practices become more evident with experience, and deciding when to vouch for them, even strongly, becomes more evident with wisdom. So I wouldn't necessarilly always distrust engineers who want to promote best practices. I would listen to them, discuss it with them, and make a decision along with the rest of the team. If they do push back after a decision has been made, that would be a bigger issue. Not necessarilly with that specific engineer―it could also be a sign of communication problems, egos, politics, etc. Unfortunately, there are many dysfunctional teams and companies with toxic environments, but I suppose that's just human nature.