I think you got most details from the others, but insurance is two basically two different things:

Life Insurance is mostly a savings product, and the insurance part protects you if you live too long.

Property and casualty insurance protects you from losses, including someone's life, but also houses, cars, etc.

The domains are quite different, but they both have specific "insurance business" computing that's related to actuarial science or analysis, i.e. the statistics needed to calculate reserves, policies, prices etc.

I doubt COBOL is used for any actuarial analysis. I think SAS is still strong, but I suspect R is used now. Maybe Python is used in the more static calculations that are handed over to developers, but the actuaries are typically coding whatever they need when they create their models.

The rest is just case management, automating business rules, bookkeeping, payments, and for life insurance also systems for trading securities and funds, and possibly in-house tools for asset management.

There isn't really a strong case for COBOL. The only reason COBOL still is used is that the insurance companies where early adopters and saw computing as a way to reduce the administrative overhead. The investments were made at a time when trusting some hippies running UNIX wasn't really on the table, and even less so trusting some nerds and their rickety PCs. They built up a workforce with COBOL devs that also gained quite a lot of business knowledge.

The digitalisation created another problem - a lot of the older employees were hired to do simple administrative tasks. Even big corporations aren't totally psychopathic so it actually has taken a long time to shift out the employees, and retrain the remainder for the jobs that got more demanding. Even the employees that didn't really have that much high-value domain-specific knowledge to begin with. So the case for more automation was actually not as strong as it could have been.

Even still, although especially life insurance is a totally digital product (damage claims is not), they primarily see IT as a cost centre at heart although they probably claim they do not.

This has shaped their systems and they have tended to replace their old systems when they're forced by external factors, as the upsides - better digital sales, more automated decisions, better trading experience for their customers,etc are not as easy to achieve as the more tangible administrative automation cost savings they started out with.

Actually, this also applies to banks. You could totally run an insurance company or bank without any mainframes or a single line of COBOL. But the organisations still have COBOL developers and maybe more important an upper management that come from that tradition.

Ask HN: Any active COBOL devs here? What are you working on?