It is important that software systems meet the business requirements. The business requirements can require long running business processes. Does that mean OO should be used. Hardly!
Shopping cart is an object. Maybe. Bank account? Maybe. Product list? Maybe. Stock in warehouse. No. Money in ATM? No. Customer is an object. Ridiculous.
What's bad about pretending things in the real world are objects in memory? So many things. It leads to so many mistakes. E.g. complex class hierachies, instead of lots of simple predicates. Objects can't change their types. Another big issue relates to invariants. OO makes people think in terms of complex constraints - even more so than RM! Lots of predicates is easier to avoid constraints. By contrast OO classes inherently impose constraints. E.g. Customer has bunch of members implies customer has those attributes. By contrast, simple predicates allow for customer to have very few attributes or lots of attributes.
Fidelity is important. Keep it real. OO starts the design around a pretense. For example, there are physical things like airplanes, seats, money in ATMs, humans, stock in a warehouse. One can hope to store facts about these physical things, but the physical things represent the truth.
For example, if the ATM is broken into and money is stolen then what the database thinks is in the ATM is wrong. The actualy money in the ATM is the ultimate source of truth.
If the stock inventory system thinks there's an item in the warehouse, but it isn't then the warehouse is the truth, not the database. This is unavoidable - e.g. stock is stolen. The business processes need to reflect the underlying reality. For example shipment of an item can fail at the last moment because the stock that was thought to be in stock actually wasn't.