I don't believe in the "some people think procedurally, and some think in OO" thing. The me that's a load of bull. Before I coded in OOP about 15-18 months ago, I used to do everything in functions, and like wise I came from a background of using BASIC on Amstrads / C64 and DOS for a few years when i started getting into programming before I moved to PHP.

I have just found it is more natural to model things in OOP. It is a lot easier to make abstractions in OOP. At the end of the day, as humans, our thinking process generally works by making abstractions / simplifications, where different concepts are "layered" on top of each other, and each concept only really knows about the concepts surrounding it. That's probably wasn't explained too well, but look at the OSI Model used in networking. Each layer in this model has a group of related concepts. The Session Layer only knows how the Transport layer works, and the transport layer only knows how the Network layer works etc. There is no way the Session or Application layer knows how to directly communicate with the Physical layer. As Marcus said things change in the (business) models that our programs are synthesising. When these changes occur, we want to do the least amount of work to accommodate for these changes we need to make. Abstractions in the way things work enable us to do this. In OO, one can achieve this be reducing the coupling between classes by making each class have one specific role. In Procedural programming, being able to something similar is a lot harder, and requires more discipline imo.

The same sort of principles apply to almost any other model (non computing related in life). Electrical Engineering is another place where this applies, where this can apply. When writing a program it is natural to take this approach where things are layered in a similar way. This is just how the human mind works at the end of the day... as humans we need break problems down into smaller problems in order to solve them. Going back to something like electrical engineering, you never see someone just come up with a design for making a new processor. The task is split into smaller problem segments (I.e. How the ALU, FPU, Cache, etc work), and delegated off to other people. The people designing the FPU might further more split up the problem and delegate the task off etc etc. This model of splitting tasks up and delegating them off to objects that specialise in that area of knowledge / domain based on responsibility is common to moreless everything in the world. As programmers it is our task to model solutions to real world situations normally, and OO is the natural way to do it, because that is the way the world works.