The process of constructing software always starts with a desire and an intention. I have a need and I will build (or get someone else to build) a tool that will satisfy that need. (In the software world we usually talk about requirements - the formal expression of needs.) The intention arises from the decision to do something about satisfying the need - in our context by constructing a software system to make images of a certain type by certain means.
As our needs get bigger and more complicated it gets harder and harder to work out how they can and should be satisfied, and even whether they have been satisfied after a solution has been constructed. Software engineers have worked out a number of methods of systematically trying to understand the world they are trying to change, describing software systems that should produce the required changes, and then building the systems. For many of today's systems there are huge gaps between the statements of needs and the way solutions can be actually constructed. Engineers need to build a series of bridges to cover the gap. Object oriented methods are one method of constructing such bridges. They have proved highly effective in suitable skilled and experienced hands and have certainly facilitated the construction of very complex systems (probably including the one you are using to read this article).
Object Oriented Programming (often referred to as OOP) is the back end of a set of techniques that start with understanding the problem (Object Oriented Analysis or OOA); working out what a solution should look like (roughly equivalent to producing an engineering drawing) which is Object Oriented Design (OOD) and finally building the system with OOP. It only really fully makes sense as part of this integrated process because much of the power of OO methods comes from their ability to make the connections between the analysis of the problem, the designed solution and the implemented program as transparently clear as possible. Before the introduction of OO methods there were conceptual disconnects between the way requirements analysis was documented, the way proposed solutions were fleshed out and the way programs were constructed. These made it hard to confirm that the essential connections were all in place, and that every requirement stated had been addressed by a feature traceable through a structure in the program. (Make no mistake: this process is never easy when you are building systems sufficiently complicated to do real jobs of work in the World. It does become less than impossible.)
Object oriented programming can nevertheless be very useful when (as in generative art) the target at which we are aiming is rather fuzzily identified - we are exploring an unknown landscape and though we might intend a certain direction of travel, we might also be very satisfied with arriving somewhere else that turns out to be more attractive than we were expecting. That can work because OOP is a very good way of making tool-kits: bits and pieces (analogous to mecano strips or Lego blocks perhaps) which can be taken apart of put together in different ways. They might help us to do our original job, but also help to do lots of other jobs as well. Part of the skill of OOP is producing re-usable collections of parts: and this includes working out what types of parts will be most useful and devising general methods of connecting them together (e.g. like the connectors on Lego blocks). The Processing system itself is one such box of tools which constructed using OO programming; the parts are objects suchs as line(), ellipse(), PImage and so on. Just about all modern computer graphic user interfaces for the applications that you most commonly use are constructed on top of graphical tool-kits built with OOP and based on object oriented design concepts.