One reason, which I think you didn't touch upon, is that OO seems to produce much simpler code, at least conceptually. I think that this is because it's much more closely related to procedural programming than the other types of programming, and because (imho, etc) procedual is the simplest type of programming, being closest to it makes for code thats easier to understand.

So OO is often taught as the next step beyond procedural, simply because it's simpler and easier to teach and understand.

Another thought is that OO tends to make code sound simpler, at least conceptually speaking, especially when speaking in more natural languages (such as english and so on). It's much easier to say Object 1 calls Object2's method baz which then takes an object3 which it manipulates in this manner, then to start describing how a functionally oriented program works.

Perhaps what I'm getting at is that objects tend to be the best way to hide implementation details, and this makes everything seem much much simpler when your trying to model something. This may not even be true when you are writing the code, but it's much easier to conceptualize.

One thing I've noticed is that occasionally you have library type code that is programmed as a class/object combination simply because thats the only way the author knows how to appropiately encapsulate his data and methods. This is often the case with Singleton pattern objects, theres no real reason to use an object in this case, you just need a module, but some times the author or the language can't use a module, so you use a Singleton object.