Like engineering, methodology an design are always tradeoffs, highly dependent on context.
Business constraints, company culture, legacy code, team strength and even individual preferences, all of that should be taken into account, there are different appropriate styles for different cases.
The only "best practice" is a wide knowledge of what can be done, and the ability to pick and mix to optimize given the context.
Sometimes the "good reason" is that a certain way won't work with the giant code base that already exists and the current way isn't actively causing any bug or major security risks. It can be hard to convince team members that want everything to be the "best" way of that, but that's a problem with people, not a problem with the concept of "Best Practices".
Every major life-or-death software system has "Best Practices". Hopefully, everyone that works on those system understands it's a fluid concept that will change as new things are learned but it's important to understand and follow them unless there's a valid, peer reviewed, reason not to.
Best practices at a minimum can be guidelines for how to build, and at there best they describe exactly what you should do based on the trade-offs and your current situation.
The coding style that is used in safety critical embedded software or high frequency trading would not be appropriate for gamedev or web, and vice versa.