OOP attempts to map to real objects, (and sometimes not so real objects). I know it's hated by functional purists, but it really does make it easier to think through problems. I personally don't hate it.
Functional purists are the only one's who hate it. OOP by its very nature encourages developers to make bold abstractions prematurely (where prematurely is interchangeable with unnecessarily) and subjectively. Mean while the procedural programmer (Golang) has already finished the segment of the program having written one big function. If a piece of that big function is needed elsewhere she factors it out. Most of her program are simple loops and conditionals. Programs are easy. Programs are easy, why complicate something that is easy.
The machine should also guide the programmer as much as possible. I wish Golang had refinement types like Liquid Haskell or ATS. Some simple static analysis to cut down on crufty slow runtime test suites.
I'm more in the data oriented design camp where you use objects all the time, but also hate what seems to be flagrant abuse of OOP by many programmers.
Casey Muratori had a good quote with regards to it (paraphrased): "Having objects in your code is fine, it's natural. We've been doing it since before OOP was a thing. It's the whole phrase 'object-oriented' that's the problem. You're orienting your thinking around objects, not functions. It's the orientation that's bad about it, not whether you wind up with an object."
