A long time ago my former boss told me something very wise. We were discussing issues we had with a banking software (built by another company). It was heavily OOP based, which was a no-brainer at that time. All of a sudden he brought up the killer argument: (cliffhanger ;)

A long time ago my former boss told me something very wise. We were discussing issues we had with a banking software (built by another company). It was heavily OOP based, which was a no-brainer at that time. All of a sudden he brought up the killer argument: (cliffhanger ;)
The ultimate task of this software is show data stored in the database and apply changes to the database. If the architecture makes these things hard, it is the wrong architecture [for this software].
Being a software developer, I immediately disagreed because I was seeing so many more things the software was doing. But he could always ask "why is it doing that" and the answer was basically always along the line of "to show it" or "to store it".
Since then, I question what the ULTIMATE task of the software I see is (nowadays mostly at my clients). No matter whether the ultimate task is coping with the database like in my example, way to often it turns out the architecture of the software make the ultimate task hard.
Over the time I came to the conclusion that OOP is pretty much always a bad choice for business software. I'm not saying OOP is generally bad, but I see its strength in other areas like UI. Just question whether it servers the ultimate purpose of the software.
I would precise that to badly applied OOP is bad for any business software, actually any badly designed and implemented software is bad for any application. And yes just to move bytes around as usual in business software you don’t need OOP. In my 25years of using OOP it was good!