(I work in mainframes, but not directly COBOL.) COBOL could certainly be done better today, but its strength comes from the fact that it limits what programmers can do with it.

In the past, there was a divide between systems and application programmers. Roughly, the systems programmers took care about the details of the infrastructure and resource access, while the application programmers worried about the "business logic" of the applications.

After the microcomputer revolution, new languages emerged and this divide was lost. "Modern" languages such as C or Java do not make this distinction. Today, programmers are supposed to be interchangeable, and they are supposed to work equally well on system infrastructure and application logic. I suspect it's partly the pride, because infrastructure work is often seen as more attractive - all the distributed algorithms stuff, scaling, etc.

To me interesting question is, was this divide valuable and should we return to it? I think so. With the advent of functional programming, it is possible to understand applications a layers of translation between different languages (see https://degoes.net/articles/modern-fp-part-2), where the language of the business problem is at the top layer, and the language of the operating system is at the bottom layer. The (application) programmers, working on the upper layers, should specialize in the application domain, and the (system) programmers, working on the lower layers, should specialize in computer systems.