Back in my dark days of Procedural Programming, I remember someone giving me a problem, then banging out a few (hundred) lines of code, achieving my goal, and going on with my life. The next time a similar problem would arise, I'd rewrite, or in some cases, cut & paste my old code to achieve a similar, yet slightly different outcome.
Even back then, I had people telling me that Object Oriented was the way to go. To me, the idea sounded simplistic and inefficient. The idea that I should make an object out of every little thing, like a Customer, seemed to me to be a waste of my time.
Over the years I began to read more about OO theory, and the fundamentals started to make a little sense. It wasn't until I was explaining to someone else the benefits that I realized how far I'd come in the OO world.
The Big Picture
Object Oriented programming is modeled after real life. Simple, there it is.. nothing more need be said.
Okay, maybe a little more. From the very first example of an object you learn (which, for most people, is a car), you realize that the way things happen in the real world can be replicated logically by designing your object to do similar functions.
The car has a color (properties), the car does thing (methods), the car responds to things it does (events), the car is built of smaller functioning parts (inheritance).
Four Major Benefits
Code Reusability
When designed in a true OO fashion, objects reflect real world entities. This type of object has functionality that is relevant only to itself, not affected by code outside of it's own scope.
For example, a Sale object would have all of the capabilities that a Sale would need, nothing more, nothing less. It would not know or care what a Customer is, because that would be a separate object. The Sale object may contain a Customer, but Sale doesn't necessarily need to know anything about a Customer to do so.
This means that once you have created your objects, they can be reused in other applications with NO recoding and/or cutting and pasting. Simply instantiate your object, and away you go.
Faster Development Time
For the initial stages of development, Object Oriented design is slower. It takes a great deal more time to plan out your objects in advance, and if you have none created that are needed for your current project, then you have to do everything from scratch. So, for small applications that have no possibility of ever growing beyond a simple task or two, OO probably is not the way to go.
But most projects we design aren't that limited. We start with our game-plan, then someone up the managerial chain from us comes and says "I need this..." and as the project evolves, our lives become much more complicated. If, from the very beginning, a project has been laid out and designed using objects, then things begin to get easier.
A perfect example from my own coding experience would be my DataGrid to Excel Export object. I spent a great deal of time up front designing and developing this object so that it would take a DataGrid as a parameter, and with one simple method, I would have my data arranged neatly in a spreadsheet. Now every time a number cruncher comes to me wanting a report that can be exported to Excel, it takes me no development time give them that functionality.
Simpler Debugging
By design, you create an object with a specific set of properties and capabilities. Rather than having one subroutine dependant on a function before it, everything within an object operates independently, which makes finding bugs very easy because they normally stick out like a sore thumb, and even when they don't you don't have all that far to go to find them.
As with my previous example, once the functionality of an object has been created and tested, it can be compiled off into its own library and need not be tested again when its used later in the project, or for an entirely new project.
Lower TCO
All three of the previous benefits add up to a greatly reduced Total Cost of Ownership. When a business can create applications faster, implement existing objects between current applications, build new applications based on existing code and have the flexibility to make a change to one library and see it reflected throughout the enterprise where that particular Object is used, costs go down; way down.
The Draw Backs
As with anything in life, Object Oriented design is not without its headaches. First, developers must force themselves to spend more time in the planning phase before jumping into their favorite IDE and hammering out code. If an OO project is going to go smoothly, every functionality MUST be laid out in advance so the developers know what objects need to be created.
It is very easy to get caught up in the speed of business and want to jump into a project head first, but in the long run, you will save a lot more time with greater advanced planning.
Another major drawback is not just understanding all of this yourself, but being able to get it through to non-programmers and procedural programmers alike. While it seems like a very natural way to create solutions, most people have been indoctrinated into Procedural Programming since their very first day of BASIC class in high school. Making the switch requires a developer to totally alter the way they look at software design. For some, that is easier said than done.
And finally, we get back to the issue of efficiency. One debate that will never be solved is just how far you need to go when defining things as object. In our Customer object, we could have several smaller objects (Name, Address, Remove..) all of which could be created as separate classes. This type of granularity could go on forever at the expense of productivity. So it is left up to the developer to decide how far down they need to define his or her objects.
Summary
As most programmers (even Procedural Programmers) gain experience in the field, they begin to see a need to reuse and simplify their coding style. Object Oriented design offers that, and allows for much more development in much less time, and the net result being a more stable product.