The closing line of the article:
>Use the primitives that are there, when possible. Write what is simple, and natural, and human.
I agree with this very much, but most of this article doesn't support this statement. Let's start with the statement it is based on.
>Eat food. Not too much. Mostly plants.
Michael Pollan is great but the human way is definitely not what Michael Pollan suggests. No human tribe ate that way prior to agriculture, which happened relatively recently, and has greatly complicated things when it comes to our diet.
So, I'm in the "Eat a lot. Not too frequently. Mostly animals." camp because I believe that's what we'd have done as scavengers and later hunter-gatherers... and since we lost most of our digestive system because of the change in diet, we can no longer digest plants well and most importantly, we are no longer immune to plants toxins, which they use to protect themselves, and a lot of processing is required to get rid of the toxins (which is seen in various indigenous diets)... and still, it is never as good as animals when it comes to toxins and nutritional value. There are other considerations which may make eating more plants sound better but I have noticed that they're not well thought-through. Also, if I'm going to be conservative about one thing, it will definitely be food. We haven't evolved for 22 million years as hominids without certain adaptations to our diets. We can't arbitarily decide to change them without side effects.
Similarly, when it comes to programming, I'm in the "Write code. However much is needed. Whatever works for you." camp, the one that I made up just now and I invite others to join it.
Objects and classes are good analogies and work well for many use cases. Humans think object oriented programming makes a lot of sense because we already think in object oriented terms. A lot of software we use day-to-day are written like that and it has worked fine for a very long time. Same is true for patterns and frameworks built on top of them. They caught on because they resonate with human way of reasoning about things. They have their limitations though.
Similarly, functional programming has a simplicity to it which works great in many applications. When complexity grows, you have to get used to various other patterns and concepts to write real-world applications. Functional programming originates in mathematics, which is also very human... but as complexity grows, it's not as human as you'd like it to be. A lot of humans struggle with complicated functional programming code, which is why it is not as popular.
When it comes to programming, there are various useful theories and tricks you can learn and knowledge you can acquire... but ultimately you are responsible for collaborating with your peers and getting the work done. So, you should choose whatever programming paradigm, patterns, frameworks, abstractions make it easy to do so. There is no "one true way" to do things.
If you really enjoy the "one true way" idea and want to take it to the extremes for fun, feel free to do so. But otherwise, there's no reason to beat yourself for not using some "superior" design pattern or programming language or paradigm. A lot of these things are context-dependent. While understanding all the intricacies and benefits and tradeoffs can be very interesting, and it is in fact explored in academia, it has little real-world value, apart of entertainment, if you just care about getting things done.