[rramadass]

> I'd love to hear an elaboration on that idea (OOP is essential for decoupling components) and its counterargument (decoupling can apparently be done just fine without OOP?).

When programmers faced the "Software Crisis" in the 1960s (https://en.wikipedia.org/wiki/Software_crisis) the idea of "Software as Components" was born as the solution (https://en.wikipedia.org/wiki/Component-based_software_engin...). This was a direct result of research on "Separation of Concerns/Information Hiding/Modularization/Structured Programming" design requirements. The idea was to make it similar to how "Components" were used in the Hardware Industry where you could substitute different components across different products/product families and all can be developed independently but used in a drop-in/plug-and-play manner to build up an entire System.

OOD/OOP turned out to be a natural architecture for Components since they provided the necessary support for the above-mentioned design requirements. There are two aspects to this architecture a) Source/Language level b) Binary/Usage level. The latter was the "holy grail" and people invented complete binary runtime architectures like COM/DCOM/CORBA/etc.(eg. https://en.wikipedia.org/wiki/Component_Object_Model) with language-neutral interfaces defined via a IDL (https://en.wikipedia.org/wiki/Interface_description_language). You could now have binary software components publish well defined interfaces which clients could call at runtime to discover and use services. The OO idea of encapsulation of data+procedures in a single "Object" keeps the model clean. But note that OO itself is merely a way of composing/structuring procedural code with a strong emphasis on a certain method of architecting the whole System.

Thus OOD/OOP helps greatly in designing systems where components can be kept well decoupled and extensible. The same can be done in a non-OO way (depending on your definition of OO) but is much harder. The design requirements mentioned above have to be satisfied whichever path you take. The role of a OO language merely facilitates the ease with which you can/cannot architect such a System.