The big draw with OOP is that (ideally) it removed the separation between algorithms and data. In traditional imperative programming, you would code set of algorithms, procedures that do different things with data, and the data itself would be stored in arrays or allocated memory accessed with pointers. With OOP you code classes that encapsulate both the data, and the methods that are used to manipulate it. So if, for example, you were writing a file manager and wanted to implement a print function, you could handle files as objects, and as long as each different file type implemented an interface that had a print() function, you could call file.print() to print the contents of that file, without needing to know anything about how the data works within it.
Of course, it's perfectly possible to do that sort of thing using defined APIs in non object-oriented languages, but there is a neatness to the way OOP works that makes that sort of thing a lot easier. OOP hides all of the details of how a class works, and as long as it's coded cleanly, it's quite easy to extend programs to work with different types of data that the original author never intended, by coding classes that implement the same base classes (or interfaces) that the programs expects.
