Why do you think it’s so important to just strive for “productivity” at all costs.
"at all costs" is likely a bad idea, however striving for productivity is a _necessity_. There are over 7 billion people, feeding and clothing (among other things) that many people could not be done with the productivity of a hundred years ago.
And it is this gradually increasing productivity in various fields that has resulted in the current 7 billion people. And they continue to grow: productivity and the number of people
You use OOP and the LCL in spite of the fact that the resulting program is _much_ larger, somewhat slower and much harder to maintain than the equivalent written without OOP and the LCL. You do it because it makes you feel more productive and the LCL encapsulates knowledge you don't have.
Can code using OOP be larger and/or slower in some cases than code using only structures and subroutines – yes, maybe, sometimes. It probably depends on what specific objects we are using, what program we are creating, what problems it is solving. And yes, it is true that we use objects (LCL, etc.) because we do not always have the knowledge of how to solve a specific problem. And that they shorten the time of creating a program (i.e. the aforementioned: productivity). But that is what programming has always been about – reusing code once written, without reinventing the wheel.
In the case of procedural programming, we also often use procedures/functions that are placed in libraries (RTL, etc.). And we use them for the same reason as classes - because we do not always have knowledge about how to solve a specific problem. So library procedures/functions are used to solve a problem, but in a slightly different way than classes. The difference between OOP and a set of procedures/functions is a matter of scale - the detail of your own source code. Procedures/functions require:
- using specific data structures, as arguments to subroutines or results of function operation - an obvious thing,
- calling functions in a specific order (often: very strictly defined) - this is also obvious.
And this second point is just as important a reason for using OOP as productivity (and can affect it). When I have a ready object, I don't have to know so many technical details related to the order of calling specific subroutines (perhaps hundreds or thousands). Because the object already has implemented calls between individual subroutines (methods). Of course, you can't completely avoid calling subroutines, because objects have methods that also often require arguments. But the multitude of minutiae and technical details involved in procedure calls is significantly reduced. Of course, after some time, interested people who have access to the source code of classes will follow it and understand how specific classes work. But this needs time.
So OOP not only shortens program development time, but significantly reduces the amount of detail a programmer needs to know. And it's not just that such a programmer is lazy and ignorant. The same could be said about programmers who use libraries of procedures/functions - seemingly lazy and ignorant, because they don't write it themselves. Because it's not only knowledge (with a capital K) how to solve a given problem, but very often even details and technical details, such source code that has been polished for years in terms of performance and memory consumption.
And finally, there is the issue of this overhead on OOP. If you do not use classes, you have to write your own procedural source code (glue code, boilerplate), responsible for calling library subroutines, receiving results from functions, etc. Is this own code so minimal (thin) that it is almost negligible? Because I have doubts about it. Sometimes this code is "thin" and sometimes not. And without this code, you cannot write a useful program based on the structural-procedural paradigm. And classes simply contain part of such code. So what is this OOP overhead really like?
And one more thing, is every OOP the same, if we take into account the overhead of code size and the drop in performance due to the use of classes? Or maybe there are differences between OOP solutions? Because I claim that these differences in OOP are in individual groups of languages: from emulated OOP (Vala), through hybrid (C++, Object Pascal) to completely OOP (C#, Java). And on the fringes of OOP there are pseudo-OOP (JavaScript, Python). And this overhead is only to a small extent due to the presence of OOP itself, and depends more on the technical details, on how it was implemented.
In any case, classes should definitely be implemented in such a way that they are as simple as possible. And you shouldn't use OOP everywhere, without thinking (but how to do it in C# or Java?).