Language comparability with COBOL isnt hard. It has well defined standards.
The problem with COBOL is that COBOL programs for the most part don't exist in isolation. They are part of long chains of operations that occur before and after they run, including operations performed by things not COBOL. Hell the SYNCSORT utility is nearly touring complete, so you have all kinds of cases where record sets are sorted, merged, selected, etc before going into some control-break-logic batch process in COBOL. A process that might be reaching into other things itself like DB2.
All of this is defined and knowable by looking at the JCL (In IBM z/OS land anyway, I am not very familiar with other COBOL environments). The challenge here is these frequently captures business rules in an unseen way. "We don't include additional site service visits in our monthly billing invoice, we send them on a separate invoice" Well if you don't recognize the previous job step produces a 'detail file' with the records that have the additional visit code, before the program that creates summary invoices runs you don't recognize that logic anywhere in the program it looks like its just doing some accumulators and control-break on customer-id to produce invoice docs. That is the real challenge with most of these systems the rules are spread all over.
It is not enough to just be able to run COBOL, you need to also be able to duplicate the environment for a lot of this business process software to behave the same. The reason to "rewrite it" isn't really anything to do with developers not wanting to deal with COBOL syntax in 2025, it is about not wanting to maintain Mainframe environment you otherwise no longer need. If you are the electric company with your byzantine rules for billing by location, customer class, contract type, volume, peak-hours, service events,.... migrating your existing process to GNU COBOL onto some Linux cluster for Z/OS is probably no more and no less rework than migrating to Python/Ruby/Java/C# while you are at it.