Because it makes it easier and safer to get programmers working together as a group.
Making OO the ultimate dogfood.
Whenever I encounter any kind of new "thinking", the first question I ask is, "Who is it good for?"
Ultimately, OO was made for us, not our customers. True, anything that helps us helps our customers, but I'd prefer to ask a more basic question...
If we have so many programmers that we need new technologies to work better together, are we doing something fundamentally too complex to begin with? Most of us aren't working on the space shuttle. We're doing relatively simple bread and butter apps moving data through logic. Before we surrender to OO, maybe we should take a closer look at why we need "easier and safer" ways to work together. For most of us, a simpler approach than OO often makes more sense. I suspect that's OP's biggest point.
Back in the '80s I was the first person in my CS dept to champion the idea of OOP. It wasn't some conspiracy to make money (not a bad thing) selling a fresh set of buzzwords (that would be a bad thing). My views were strongly influenced by the views of writer Michael Jackson, who pointed out that every program contains a model -- at varying levels of explicitness -- of its domain. OOP just seemed to make the model clearer by creating a more explicit mapping between the objects in the world and those in the program. Grady Booch and Bertrand Meyer later made similar arguments specifically about OOP.
What happened next was that an idea that worked well in a few contexts (discrete simulation and graphics/GUIs) was expanded to almost all kinds of programming where it didn't work as well. That's because a lot of the world-to-be-modeled is more verb than noun. That in turn means that functions will make better models than objects.
I now think that Lisp-class functional languages (using, say, Clojure) are better for most programs. The reason, as pg has pointed out, is succinctness. The problem with OOP is that it's hard for it to be succinct because new data types are constantly being created and new methods added to them, all of which requires extra code.
All programs are programs about a particular domain. Programs become succinct when the language being used can be sculpted to the domain at hand. That's best done in languages with macros and a simple (e.g., s-expression) syntax.
One last point. I've looked for many years for the One True Programming Paradigm. I no longer believe that any such thing exists. Different classes of problems simply require different approaches. What I've come home to is using a language that allows easy creation of DSLs and controls side-effects, while still allowing them. A wet clay language that allows experimentation and sculpting to the domain at hand. Lisp-class languages do this best, with Clojure at the top of the heap in my opinion.
I still think that OOP is best for GUIs, where state is inherent in the domain and inheritance can pay off big.
I think it's more that OO was created because lots of programmers couldn't be bothered to exert discipline in observing APIs, so discipline was forced upon them.
I'm not sure what you mean here. How does OO force APIs on a user more than any other programming style? If you don't follow an API, your code won't work whether it's OO or not.
Making OO the ultimate dogfood.
Whenever I encounter any kind of new "thinking", the first question I ask is, "Who is it good for?"
Ultimately, OO was made for us, not our customers. True, anything that helps us helps our customers, but I'd prefer to ask a more basic question...
If we have so many programmers that we need new technologies to work better together, are we doing something fundamentally too complex to begin with? Most of us aren't working on the space shuttle. We're doing relatively simple bread and butter apps moving data through logic. Before we surrender to OO, maybe we should take a closer look at why we need "easier and safer" ways to work together. For most of us, a simpler approach than OO often makes more sense. I suspect that's OP's biggest point.