"I don’t dispute this point. It’s absolutely valid."
I do dispute it. Patching is not hard. It's incredibly easy to the point that some places and projects have the process automated from notification to application to testing for breakage to deployment. For reducing downtime, one can use clusters with rolling deployments of patches. Patching is only hard for things such as web applications when the company's application or processes are done in a way that makes patching hard. As in, they have to be incompetent or just not care about IT. Far as competence, your claim about fragile systems is a good example that might have happened.
" then you’ve implicitly made the decision that you’re never ever going to allow those vulnerabilities to fester."
You're thinking like an engineer that cares about quality. You instead should think like an Equifax CIO or something. To start with, this is a company that collects PII against people's will to sell to third parties for their main goal of huge profits. Politics plays more a role than engineering talent in people getting the senior, management positions in such companies. They also tend to chase whatever is popular among Fortune 500, esp with cheap labor or ecosystems available. Java was one of the fads that financial sector was all over. Combine all this to have a company whose fad-chasing CIO keeps costs down and profits up applying the thing he or she read in a computer magazine with the cheapest talent available on a tight budget. The result of their work is a pile of garbage they have trouble patching. If you doubt this, just look at the security of the web site they deployed for credit monitoring and apparently to help hackers get at people interested in credit monitoring. Or they just made mistakes so easily avoided that they're either inexperienced beginners or don't care at all.
"So what would those systems look like?"
Well, they would have built it some time ago. So, let's work our way from old, high-assurance security toward something commercial and affordable from at least 2000-2005 era. The original work in securing data involved security kernels:
https://www.acsac.org/secshelf/book001/19.pdf
Several of those are still available but expensive. Both security kernels and databases such as Trusted Rubix built for them. Today, those look more like the next link with companies such as Sirrix and Green Hills selling them commercially:
https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
In any case, we'd need a robust combination of OS, database, and application code. Nothing hits the database without going through the app server first. So, we embed our security policy into app server. How to implement it? Ever since Dijkstra's THE OS (1960's), we knew to specify correct behavior with preconditions, invariants, and post conditions. Then use anything from formal analysis to testing to runtime checks to ensure that behavior is enforced. The security kernels did the former where Design-by-Contract in Eiffel used tests and runtime checks. Got to pick method with best bang for buck. Two links to illustrate safer languages of past with Ada 2005 since we're looking at earlier stuff.
http://www.adacore.com/knowledge/technical-papers/safe-secur...
https://www.eiffel.com/values/design-by-contract/introductio...
Given labor situation, we use DbC in a safe language. All prior work showed simplicity was necessary for security. So, it would be an app server done in Eiffel, Ada, or (if absolutely necessary) Java/C++ using Design-by-Contract methodology plus lots of testing. The web component would be a middleware done similarly that basically translates web actions to simple protocol the server uses for requests/responses. Any new types of problems with web apps are mitigated in the simple framework a la Airship CMS, caught with some kind of monitoring a la Spectre, or both.
This would have to run on something robust. You'd have the database/storage, app server, web component, management, and monitoring which is behind one-way link (data diode) w/ logs copied to write-only media. A company from likely mainframe background now run by wise technologists might first make the software target IBM but portable. Balancing reliability, security, and cost, the best targets would be AS/400 or AIX. The former is a capability-oriented architecture with few 0-days whereas other is a rock-solid UNIX. Portability means they'd migrate part or all of this to new OS's as they showed up. Eventually they'd notice OpenBSD's security advantages or buy one of those certified-secure kernels w/ POSIX layer. Depends on their viewpoint and budget. Probably throw some clustering software with rolling releases in there since OpenVMS and NonStop had high-availability in the 1980's. It was well-known strategy.
So, there was a straight-forward way to make a robust stack with a web front end which gets more robust over time. This could be done in high availability or just easy patches. They instead end up with fad-driven crud possibly running on other crud that's easy to hack but hard to patch. Just bad engineering that's typical in the market versus methods such as I described. Also note that there were (are) large institutions using some of what I recommended for those benefits. The tools and people just cost a bit more which doesn't align with incentives of companies as greedy and IT hating as Equifax. Sure turned out extra profitable, didn't it? ;)