That is not any COBOL I’ve seen. Straightforward, well documented and comprehensively specified and tested.

When we needed changes (this was back office clearing stuff for a bank) they wouldn’t even talk to us until we specced out the changes we wanted in writing and often the specs we submitted would come back with requests for clarification. This was like the opposite of agile, but I don’t recall any bugs or defects making it into production.

This was my experience too.

Modern software engineers would hate that kind of red tape because we've been conditioned to want shorter feedback loops. Heck, I hated it back then too and I wasn't even accustomed to seeing my results instantly like I am now. It takes a special kind of person to enjoy the laborious administrative overhead of writing detailed specs before you write even a single line of code.

Kind of reminds me of taking pure CS101 (I.e. no programming language; just theory and sacrifice)

COBOL code I saw in the 80's and 90's wasn't spaghetti code. COBOL is pretty structured. If it's not, that would be a prior step in porting it to another language.

I don’t buy that vintage of code is an indicator of its quality.