I'm not sure object oriented programming ever really caught on. The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go".

> SQL is already a high level abstraction.

SQL is a high level query abstraction, but we're talking about the data model. Again, a relation is nothing more than a set of tuples[1]. That is a very primitive data abstraction.

Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures?

> The models already exist in the database. Why build a repetitive model in the application language?

Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code.

> It's a cosmetic thing because people don't want to deal with string manipulation.

String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory.

[1] If we are being pedantic, SQL actually deviates from the relational model by not staying completely true to sets. But the terminology has stuck regardless.