TLDR: you have to find the underlying context of the advice; when is it good for what. when you have your own reasons to adopt, then you'll also know when to let go (not wait for someone else to disband the party)
Don't just blindly follow the advice of "experts", take it with a grain of salt.
is prudent advice regarding following advice... but not enough; it's just varying the level of trust. Instead of only adjusting trust % level on what people tell you, try it out. for real or thought experiment on your past projects.
e.g. coming from years of writing Ruby to writing Go, i was accustomed to plucking the values out from os.Getenv wherever I needed it; there's a certain "plug and play" to doing things this way. chuyeow's PR reviews kept pointing out that cli flags are preferred and that it's ok to pass them in through function arguments to where I needed to use them. Though I didn't agree with the practice, nor could I see why it would be good in Go context, I went with it to see how things will pan out. Regarding this and other advice along the way, whenever the benefits borne out or downsides felt, I do make it an effort to revisit the contention and get back to him "yes i now think this is good because..." or "this problem we face now is because... wdyt?". I recall he wondered why I'm "keeping scores" but it's not personal win/lose score keeping; I'd just wanted to share my learnings so i can remember the reasons myself.
I forgot whether i pointed you to https://www.joelonsoftware.com/2002/05/06/five-worlds/ before. the content is rather dated, but the underlying point is very relevant: advice usually has an unspoken context, and if your situation is similar it could work but in another context the advice could be irrelevant or even wrong.
When i was in the J2EE world, i was trying to catch up to learning "best practices" (and there's a LOT of that in Java-land). only when i was exposed to "a different OOP" from Ruby, then it was shown to me that "could some of those best practices be just workarounds for the flaws of Java?" i.e. "when writing java code you should..." instead of "when writing software you should....". that might have been my first experience of what joelonsoftware was talking about.
For example, a lot of people formed the opinion that "hey, you should check out Robert C. Martin's book, Clean Code" and then there would be someone out there stating that his book isn't good.
I have not read the book. I did come across SOLID principles occasionally, but they didn't stick. Whenever I do google the principles, I'll find myself asking "is this a good thing all the time?".
also, they could be a bit too OOP specific. and if like me you start losing faith in OOP, then these best practices start to look like they are built on top of sand...
NEVERTHELESS, you could sell me on some stuff from the book, and i'll let you know my take and any context that I spot?