This gets down to the programing equivalent of "religious issues" to give you a complete answer. Different people (even different experts) will see the question in a different light.
Object-oriented programming in its pure form allows you to design classes of objects, then create instances of those classes. A class is basically a "template" for the object, in that the class knows what kinds of things the object needs to know about (attributes), and what kinds of things the object does (methods). When you use this class template to instantiate or create an instance of an object, you basically cause a new object represented by that class to exist in the scope of your program.
Particularly when modeling physical objects with complex interactions such as planets, communications equipment, invoices, etc., the object model allows the developer to think on a different level of detail than is typically possible with structured code. The developer can think about what attributes an object needs to know about and how the object needs to act on those attributes. The system then tracks much of the detail involving interactions of objects, and manages much or all of the "gory details" of memory management, etc.
OOP languages also usually support inheritance, which means that you can define general objects that have basic features common to whole sets of objects, then build upon those generic definitions to create more specific objects from them. For instance, if you have a generic object for a Christmas tree decoration it might have characteristics like weight and color. You could then subclass this general definition to make new classes for light strands, garlands, and glass bubbles, each of which would have the basic weight and color, but would add new attributes and methods that would further define these new subclass of objects.
Simple tasks are usually much better accomplished through structured programming. Structured programming uses a "divide and conquer" metaphor, much like the way that outlining is taught in grade school. First pick out the major tasks that need to be accomplished, and these tasks become modules. Within each task or module, identify components or building blocks and they become functions. This stepwise refinement allows a problem to be broken down into its component pieces, and (at least hopefully) cleanly converted to application code. Typically, this results in FAR less overhead for the machine to execute in order to solve a problem than an OOP solution requires to solve the same problem.
There are a number of languages such as C++, Perl, C#, etc., that allow you to use either approach at will. Problems that are object oriented can be solved that way, while problems that are not can be solved using structured programming. There are a few trade offs when using these languages, but they generally offer the developer the most choice in how to deal with a problem.
If I had to create a model of an aquarium that would graphically show what happened over time, I'd definitely choose an object-oriented approach. If I had to write a script to backup my database and verify that the backup was safely and completely stored on another server, I'd choose the structured programming approach. Many times the environment in which my code must run selects which method I have to use, and sometimes those solutions become quite "interesting" due to the choices of tools available.
This was first published in November 2002