I assume by "best practices" you mean some list of rules that someone wrote in a book. For of course if you mean the phrase literally, then of course you should always write the best code you can.
Need I point out that there is not a single, universally-accepted set of "best practices"? For any rule promoted by one expert, you can almost always find another expert with equal credentials who says something different.
But to the point: Short answer: usually, but not always.
Every field has its "best practices" and "textbook solutions". These represent the accumulated experience and wisdom of many, many people over many, many years, and should not be ignored. BUT! There are always special circumstances, fringe cases, etc. The truly capable person in any field knows when to follow the rules and when to break them.
I'd say in general: Start out by following the textbook rules. When following the textbook rules leads to trouble -- unnecessary complexity, poor performance, whatever -- then consider whether breaking this one rule this one time might not be a better idea.
If you ignore the rules and go wherever your whim of the moment leads you, your code will likely be a jumbled mess. No matter how smart you are, you are not the first programmer in the world. It makes sense to learn from the experience of others. In our daily life, this is why we have parents and teachers and preachers: so we don't have to repeat every stupid mistake ourselves in order to learn that it is a stupid mistake to make.
But if you slavishly follow a list of rules from some book 100% of the time, you will often find yourself hammering a square peg into a round hole. The people who wrote the rulebook may not have come across a case quite like yours. And even if they have, if it's rare enough they may have ignored it. A rule that works 80% of the time is an excellent rule -- as long as you understand that it works 80% of the time and not 100% of the time.
I wrote a book on database design that includes many rules that I advise database designers to follow. (I'll refrain from giving the title so I don't look like I'm shamelessly slipping in self-promotion.) I certainly encourage anyone who wants to design a database to read a book like mine and learn all they can from it. But OF COURSE there are times when you should break the rules I list.
I once wrote a programming standards document for a team of developers that I led at the time. And the last rule went something like this: "If you have a good reason to break one of the above rules, then go ahead, BUT you must include a comment in your code explaining why you broke the rule. If you can't come up with a good reason, then follow the rule. If writing the comment is more trouble than following the rule, then follow the rule." We had only a handful of times that someone found breaking a rule worth the trouble of having to explain why.