Whenever a "best practice" or "convention" has been presented to me, that is how it has been framed. (...it is best practice, therefore, it will definitely benefit you to follow it)
In many work places either they do not have time or at least think they do have time to think things through 100% for themselves from first principles so they depend on best practices instead.
That makes sense to me and I would expect better results on average with using best practices than rejection of best practices in the above context.
That said I try to work on things where I am not always in the above context, where thinking things through end to end provides a competitive advantage.
There are plenty of them that help us write concurrent code that avoids common deadlock situations without having to resort to writing proofs every time. Someone already did the work and condensed it down into a rule to follow. Even if you don’t understand the underlying proof you can follow the rule and hope that everything will shake out.
What I find we struggle most with is knowing when we actually need to write the proof. Sometimes we bias ourselves towards best practices and intuition when working it out formally would be more prudent.
It’d be ideal if you could identify when it doesn’t work. But in the absense of that applying it everywhere is still a net positive.