Less dead than perl by far. I've seen a lot of new COBOL going into production just this year. New versions of the compiler (the IBM one, the only one that really matters for COBOL) are still being released. A while back they went to the trouble of implementing full JSON serialization/deserialization. You would be surprised how many web services are pretty much just COBOL the minute the server needs to do anything with files or databases or whatnot.
As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.
It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.
For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.
Microfocus COBOL also matters - there's non-trivial amount of code that is still being worked on, in COBOL, that runs these days mainly on RHEL machines and is compiled with Microfocus.
As for handling destructuring files, how useful it is really shows when you consider how easier many tasks become when you have access to such facility - even if nowadays you might expect it to be handled by extra compilation step that uses protocol buffers or something similar.
Modern programming languages are more than capable of providing an abstraction layer that can offer seamless file->struct and struct->file conversions.
It's basically the equivalent of ORM for relational database.
But nobody does it not because it's hard or because the language doesn't support it. They don't do it because we no longer think of file system the main "database" that stores your application state.
Instead we think of the filesystem as a lower level building block for higher level abstractions (such as relational or whatnot databases)
Since we're talking about languages, a better question would be "is a language in which no new works are written but which has a large catalog of past works that are still studied by thousands of people 'mostly dead'?"
The many COBOL programmers are not being paid to study a dead language, they are being paid to adapt, evolve, and maintain living systems written in that language.
Can we say it's mostly dead?
For example, is it more or less dead than perl?