There are million paths that can lead you to your target. Well, maybe not literally a million, but usually at least two :) And very rarely one of those is in clear way better than the others in all the aspects you take under consideration when making the evaluation. Sometimes, one of the paths is just “good enough”, so why bother with digging deeper (spending time on analyzing other possibilities)? Isn’t it what we call the basic economic sense?
And sometimes you’re tempted to go shortcuts, against the core concepts of given lib / framework. Either because it’s faster, requires less boilerplate code or you’re more familiar with this way. Or sometimes you don’t feel comfortable with the “recommended” (by-the-book) approach. However, I’d like to discourage such actions - in vast majority of cases, creators of tools really know what they do, as they had an opportunity of testing it on many RL scenarios before. I’m not saying that you should blindly follow what’s in tutorials / docs, but it’s crucial that you understand the idea behind the solution you’d like to use (before you deny it). If you don’t, it may appear that this library is not really suited for you and you’re wasting your time and effort on making it fit, but in the same time you could use something different, that would work better in your scenario (without twisting it around that much).
Believe me, I went through that sooo many times, and for instance - it still pisses me off when I see that people use the very first opportunity to neglect the MVC approach in the framework of choice that heavily relies on that pattern…