Is OOP really beneficial for enterprise-scale business software compared to procedural languages like ABAP or COBOL?

I strongly suggest you critically review your pain points and reflect how much of this is attributable to OOP inherently, versus inexperience stemming from what is clearly a workplace that is not highly experienced with OOP.

These two categories of problems need to be addressed differently and your current question does not reveal any context/justification for your alleged conclusions on the pros and cons of each approach.

Given your biased perspective (not an accusation, everyone has some kind of bias), allow me to offer a perspective from the other side of the fence.

On the topic of OOP

OOP often pushes for wrapping everything into a class, even when a simple function or structured dictionary would suffice.

A dictionary is an object. The distinction you're making here is between whether you built the type or whether it came out of the box with the language you're using.

Additionally, functions not wrapped in an object have no higher abstraction capability. This is fine for pure functions, but pure functions are not the be-all-end-all in an OOP world and you cannot fully cover an OOP design using pure functions. In that sense, they are polar opposites, although realistically an OOP codebase can contain pure functions to some degree where relevant (e.g. tiny helpers).

I do not see the concern with wrapping your pure function into a static class. Line count is not a valuable metric for software development quality/velocity; so what's the actual problem here?

Modifying one class often requires rebuilding or redeploying the whole system.

That's just bad encapsulation and abstraction then. The point of having the abstractions is to put a blast shield so that a change in one implementation does not (necessarily) impact everything else. I say "necessarily" because for sufficiently disruptive changes it's impossible to handle them silently.

For any implementation change that does not come with an interface/contract change, the change should be handleable within the specific class without affecting other components.

If (almost) every implementation change inevitably leads to an interface/contract change, then you've designed the wrong interfaces/contracts.

If your ongoing development constantly forces you to reconfigure your (properly designed) interfaces/contracts, then your development process is not a productive one.

OOP encourages abstract structures that often do not map well to real-world business data or process flows.

This is likely the source of the previously listed issue. Abstractions are what you use to help represent bigger picture application flow and requirements. The fact that you point them out as obfuscators to the real flows suggests that you're not using interfaces and abstractions in the manner they are intended to be used.

Inheritance and interface trees become hard to trace, especially in large teams.

Based on the premise of my previous observation, this would be an expected symptom.

Ill-designed abstractions create more confusion rather than resolving it, leading to unintuitive code design and forcing developers to understand and handle nonsensically designed components, which significantly increases cognitive load for developers and making it harder for them to not make mistakes and have the mental capacity to properly tackle/design their current task.

On the topic of procedural code

and simpler reasoning about data flow.

This is a mindset problem. Based on the issues you point out in OOP, you're trying to do procedural/functional programming in an OOP syntax and expecting to get the same benefits out of it. You're trying to force a square peg into a round hole.

The blame does not lie with the peg, nor the hole. The blame lies with the expectation that the OOP hole should facilitate the peg you're used to working with. To adopt OOP you need to change your mindset and how you compartmentalize problems and design solutions for those problems.

easier onboarding for junior developers

The ease of onboarding is generally derived from two things: how intuitive the codebases are to read (for people who did not create them) and how well your existing staff is able to guide the newcomers.

You seem to be fighting an uphill battle on both of these fronts. Your code is not intuitive (as per the previous OOP section and the problems you are pointing out) and based on the overall question is appears that OOP experience is rather low in your team, rendering your developers less able to clearly guide newcomers into the OOP way of doing things.

granular deployments (only the changed module)

In the OOP section you point out that a change in one component forces changes in a bunch of other components. If that is the case, then the inability to deploy subsets of your code is an inevitable knock-on effect.

The granularity of a deploy is not directly tied to whether you are using OOP or something else. It is tied to how cleanly separated and loosely coupled your modules/components are, and based on the problems you point out it appears that they are tightly coupled, which inevitably leads to an inability to give these components independent lifecycles.

This is not an additional problem, it's an additional symptom of the same underlying problem.

On the topic of your concluding questions

Are there empirical studies or industry experiences supporting the continued use of procedural languages in such domains?

Business software development is generally a human problem, not an empirical one. Not only does this require accounting for non-technical factors on the business side of things, companies also tend not to publicize their internal technology failures (doing so does not benefit them and can severely harm them), which makes an objective empirical study impossible to draw any meaningful conclusions from.

This is also not the right tree for you to be barking up, in my opinion.

In enterprise-scale systems focused on data access and batch processing, is OOP truly more maintainable or productive than procedural design?

OOP does not relate to runtime performance. It relates to design of the code and how developers navigate their codebase, and how it is set up to handle incoming changes and design variations during an application's extended lifecycle.

Which parts of OOP (e.g., inheritance, encapsulation) tend to hurt maintainability in these contexts?

This is a loaded question based on the premise that your attempts at OOP are fully indicative of what OOP is like - as established in the opening section this is not the case and your question's content does not contain any information to support such a conclusion.

Have any large organizations intentionally avoided OOP in favor of simpler, procedural or functional architectures?

What an organization chooses to do has no bearing on what is actually better/more applicable for their use case. The field of software development is littered with instances of technical staff being forced down a path that they feel is the wrong one - often due to decisions made on a non-technical management level.

Furthermore, the size of the organization is irrelevant at best, and anecdotally it is generally accepted that larger organizations tend to be less efficient about their design perspectives, often because they tend to put a higher emphasis on standardization across the organization even if it leads to inefficiencies in individual use cases.

I'm not asking whether OOP is "bad", but whether it’s the right tool for this particular category of applications.

Your question is loaded and biased (not an accusation, I believe this is unintentional) and it's rendering your concluding question not meaningfully answerable.

Your scenario is one where you've shifted from using wooden planks to metal pipes, and you're trying to point out that putting metal pipes together with nails is way more difficult and leads to an inferior result. You're not wrong but the issue there is not between whether you should use wood planks or metal pipes, it's that you're still trying to use nails instead of learning to weld.

The core point of the analogy is that you're not doing the new thing in the right way (based on the problems you point out), and therefore your musings on this new thing are not an objective judgment on the new thing. This is a variation on Dunning-Kruger, you cannot judge something if you're still new to it and you're making mistakes with it.

It seems like you and your team are most comfortable with procedural code. This is totally fine, and prior experience by the team is a very good argument for selecting a technology. But you are not going to find any "objective" research showing OOP in general is a bad fit for enterprise-scale software. Lots of opinions, sure, but nothing scientific.

In a data-processing application it makes sense to center the data structures as separate from the operations, while OOP tend to hide (encapsulate) the data and only expose the operations. So a procedural style could would well be the most appropriate for your case, especially if the developers are unfamiliar with other styles.

Python is a multi-paradigm language and support both procedural and object-oriented style. So you should think of OOP as a pattern to apply when it provides value, rather than a paradigm. If something is simplest expressed as a stand-alone function, there is no need to put it into a class.

That said, some of your grievances against OOP seem to be based on misunderstandings. You say procedural allows granular deployment while OOP require deploying the whole project. But the smallest deployment unit in Python is a single file, i.e. a module. It doesn't matter whether that file contain functions or classes. Of course if there are dependencies to other files, you will have to deploy them also, but this is the case for either style.

The other criticism against OOP is about overly-abstracted hard to follow code. This a legitimate concern since the OOP community do have a reputation for over-abstracting and overly complex design. But you don't have to do that if you don't want to. If someone writes "abstract structures that often do not map well to real-world business data or process flows" then that is the fault of the programmer, not the programming paradigm.

Your question pretends there could be a technical problem with applying OOP to enterprise business software - but in reality, I think this is a mainly a people problem.

In an environment focused on data access and batch processing, people who apply for a software development job are often people who are satisfied by maintaining such kind of software systems, written in ABAP and/or COBOL. It is IMHO a difficult to convince most of these guys to learn a different programming paradigm, something which will require an extended skill set to do it right, coming with a lot of possibilities to make new mistakes.

In such a working environment, one will have a really hard time to find any benefits in this new paradigm - not because there are not any, but because there are not enough people in the organization who are willing to fight themselves through one or more extra years of learning effort.

It's like trying to persuade the local music club to play with the instruments of a symphony orchestra. A symphony orchestra with trained musicians could certainly make more appealing music, but if a person who has only played the timpani all their life is now suddenly asked to play the violin, you shouldn't expect the result to be a brilliant performance of a Mozart symphony.

If I would try to introduce some OOP into an ABAP or COBOL environment, Python would probably not my first choice. ABAP as well as COBOL both have evolved over time to allow OO programming (see here and here for some references). This may increase chances your senior developers will learn some OOP and adopt it sucessfully into their work - smooth transitions are usually easier to establish than a cultural shock from COBOL to Python.

Have any large organizations intentionally avoided OOP in favor of simpler, procedural or functional architectures?

Yes, from the point of view that SQL is almost ubiquitously used in all current development of business applications that store data or process data in volume, and COBOL is still said to be the most prevalent programming language in extant codebases (especially in the largest and most economically important areas, like governmental, banking, etc.).

Which parts of OOP (e.g., inheritance, encapsulation) tend to hurt maintainability in these contexts?

Let me reset the perspective here. The main issue with "maintainability" actually has little to do with the language used, and more to do with the fact that businesses habitually fail to retain and reproduce knowledge of their computer applications, of the business functions which those applications automate, and of the "development culture" around certain languages and platforms.

What many managers are implicitly searching for in this area is a holy grail language, the usage of which means you no longer need to teach the kids how to read and write it, and you especially don't need 20 or 30 years' worth of teaching curriculums and the infrastructure around that.

This is where the obsession with "documentation" once came from, though almost everyone has by now learned that it is an ineffectual waste of time when used in substitute for continuous staffing.

If we were to focus specifically on OOP though, I think "inheritance" is regarded as a language feature which contributes to maintenance problems.

The two reasons for this are (a) because the concepts of the world rarely compose together neatly into the hierarchies implied by inheritance, so an ad-hoc and poorly-considered hierarchy often results, and (b) when concepts have been successfully composed into a particular hierarchy on a particular occasion, that hierarchy often cannot withstand change and then a big overhaul is required. Or some kind of version split is required, where some things require the old hierarchy and common code, and some parts require something new. When inheritance is used judiciously, it is usable so rarely and in so limited a fashion that it is unclear that it carries its own weight as a feature.

More broadly, I think the problems with OOP are less about how an OO language mandates problems, but about how a broader OOP approach admits and suggests (though does not require) unsound conceptualisations amongst programmers, or helps to promote relatively obsessive concerns or create dilemmas about things that are often less important.

I think for enterprise development, you'd be considering not just the language but also things like the built-in libraries, the documentation and availability of code examples, the support from the vendor, the quality of the IDE, the integration capabilities, the availability of experienced (or willing-to-learn) staff, and so on.

Also, creating an extensive style guide is unlikely to promote efficiency in your organisation - it's more likely to promote combat and distrust amongst colleagues, and generate staff turnover, things that are especially harmful to development and maintenance (certainly far more than any of the style issues you're focussing on).

Developers who are accustomed to managing themselves (which is an opponent who very rarely disagrees) and managing the computers by fiat, are often unaccustomed to the idea that other professionals, who may have very different habits or opinions on various matters, cannot be managed in the same fashion.

I am sorry if I will not answer what you want to hear: no OOP is perfectly fine for enterprise grade code bases. It's not without reason that it emerged as dominant model:

• First of all, OOP also allows small and modular programs. Even better, the modules are themselves composed of even smaller and interchangeable classes, that with some discipline, avoid change propagation across large parts of the code base;

• Zero down time deployment is not a question of programming language or paradigm, but of architecture and design. There are massive OOP code bases that run internet services without down-time. Microservice architectures aiming at facilitating such deployments are often developed using OOP (even if they could as well use procedural languages).

• Absence of data abstraction seems rather a drawback than an advantage. From what I remember from COBOL, one defines very well data structures. But one has to repeat over and over again code when data structures are similar and it is more difficult to achieve separation of concerns. Moreover there is simply no way to enforce the data structures are used correctly. Error-prone. Not friendly to junior coders. Painful to maintain because of the repeat/adapt that you have to sometimes make.

• Apparently, OO features tend to be heavily used in Python code bases as a study shows. So I would not be surprised that Juniors joining your project and having some Python background, would in fact be as comfortable with OO than with procedural if not more.

By the way ABAP is very well object oriented, and this since more than a decade. Ok OO comes as an option, but I have seen complex ABAP code bases maintained efficiently thanks to the language's OO features.

I have heard that COBOL was never made object oriented, because the experts could not agree if it should be called COBOOL or COOBOL - lol - sorry for that joke, there are actually people working on Object COBOL at Microfocus and ANSI.

I will not go through the remaining arguments as they are very detailed and seem not well founded by evidence. Each of them could deserve its own question, but based on facts rather than hearsay or own personal impressions.

Today, you will find many OOP developers and quite a few competent ones.

Now find me a COBOL programmer who isn’t looking forward to retirement. Nobody with any talent will want to get into it, because it is just a dead end.

PS Inheritance in OOP was very much overrated, you will usually not even have subclasses anymore except subclasses of one very widely used baseclass.