Object-oriented methodology allows representing the system as a hierarchical structure of self-contained subsystems and entities comprising it. This allows separate development and testing of the subsystems apart from each other, good code reuse (through inheritance - similar objects; and through use of object libraries - use of pre-made objects by 3rd parties) and abstracting internals of subsystems apart from the systems using them, creating consistent interfaces between them, easy to extend, debug and modify.
For an easy analogy: You build the big system out of big bricks, each of which you build of smaller bricks, and these - of yet smaller, each with own quirks and special purposes, some being just special variants of others, others being pre-packaged ready-to-use bigger bricks. They all need to fit just right, but if you make a small brick of the tiny bricks and it fits just right with the bigger brick, you can just reuse it everywhere it's needed (and if it's faulty, you can pinpoint the fault and fix it easily.) If you started building the entire system out of the tiniest bricks from start, you'd end up with a mess where every segment, no matter how common, needs to be made from scratch all over again, and if something's broken, you don't follow the simple chain big brick; smaller brick within it, even smaller within, the bad tiny one - you'd need to track all the hundreds of tiny bricks from top to the faulty one through that mess.