> knowing why those things are there

I'm pretty sure they're talking about converting COBOL to Python or Go and that is the benefit. That doesn't require knowing the architecture and system design. I'm not familiar with COBOL and COBOL systems so I could be wrong... but Python programmers who can then study the system are easy to find.

This is fintech - I've not worked in banking specifically, but fintech (or fintech adjacent) most of my career, and from my POV these things can get insanely complicated in very unintuitive ways because the financial world is messy and complicated.

I've never worked on COBOL systems specifically, but just going from my experience working on fintech problems in dense legacy stacks of various languages (java is common), that are extremely hard to understand at times, the language itself is rarely if ever the problem.

"Just need to convert it to Go or Python" is kind of getting at the fallacy I am trying to describe. The language isn't the issue (IME). I do have my gripes about certain java frameworks, personally, but the system doesn't get any easier to understand from my POV as to simply rewrite it in another language.

Even let's say it was this simple in the case of COBOL - these are often extremely critical systems that cannot afford to fail or be wrong very often, or at all, and have complex system mechanisms around that to make it so that even trying to migrate it to a new system/language would inevitably involve understanding of the system and architecture.