You can use OO design (which is more what you are alluding to) for anything. It is just more applicable in some cases. OOP is just a way to code up an application - without a good design behind it the result can be very poor.
The point of OO is to break a problem down into it's constituent parts that makes it easier to understand, design, implement and maintain. HOPEFULLY. I've seen a number of bad solutions in my time.
The theory is that if you can encapsulate the behaviour of something in the system into an object that hides how it does something, but not what it does then you get the benefits of OO. The development of the object is easier because it is wholly contained and protected. It doesn't care what the rest of the system does. It hides how it works so no one is dependent on that implementation.
Development of the program is easier because you are not worried about understanding the details within an object. You just look at what it can do for you.
It is best applied to programs where clear definitions of things that maintain state and have behaviour exist. For example, programming an ATM could have classes for users, transactions, the hardware in the system. A simple backup program could have classes for storage media (tape, vs. disk, vs. off line systems), and files (to read, to archive, to restore).
Good reusable and extensible (can I modify it to do more) OO takes a lot of practices and a lot of thought. Not something that should be taken lightly.
It takes many people a while to truly understand the concept and how best to apply it. Using the programming language is the easy part. Creating something practical and usable takes more time.