This is only good advice if you're solving very simple, very trivial problems, or if you don't have enough experience. (That, or if you redefine best practices to tautologies like "always test" or "always write good code").
For anything more complicated than the most trivial of software, it's important to deeply understand your best practices and if they make sense to each situation or not.
but why should they?
For example, you may have a rule that you need CI to pass to merge a branch to your trunk.
But maybe CI is slow and flaky, and a business test fails on a PR where you've only changed the README.
Sure, you can say "well, the rule is to only merge with green CI" and restart the failed job, but you can also think "well, I can merge this".
Maybe it's ok, maybe not, but I think you should trust your fellow developers with doing the right thing rather than berate them "you didn't follow the rules!"
What it means is whatever you or your company decides are best practices as well as agreed upon industry best practices must be followed every time.