This is of course depending on the complexity, but in general I would say the answer is quite easy... Yes! You say it is a COBOL-like language, how many people knows this language?
If this developer have a heart attack or becomes unavailable, who will be able to explain when someone new needs information about the design?
Time is money, to get up to speed and start do something that makes profit. It goes quicker to browse through the documentation to understand how things are supposed to work before messing up the code.
If you need to bring in some external help, it would be both cheaper and quicker if they can read the documentation.
There are other things you can't see by looking at the code itself. Thoughts about future expansion. Some code might look really stupid but is designed in a way for a coming feature or expansion.
If the company's business is relying on this program, you really want it to be documented so you can fix problems fast if something happens (for example if the key designer get pissed and leaves).
We all find it a pain in the 'A' to write documentation. I can recommend auto generated documentation such as Doxygen, a great free tool that reads your code and draws call diagrams and collects comments into either a Help file or a HTML manual. I don't know if it can handle your Cobol-like language, but there are scripts and variants that extends it to handle more languages.
We usually made a lose design document before starting a project, then we document with Doxygen style comments in the code. That was effective enough to bring in new people up to speed quickly...