That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.
They literally can't run without porting, disregarding performance. The benefit is infinite!
Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
It's just an Apple trick to force financial turnover for owner of 32 software.
It's not that there softwares are not compatible anymore, it's MacOS which block artificially 32 bit software.
It's for the same reason MacOS block sidecar for device older than 2016,even if they are capable to run sidecar in the first place.
Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
A better example is the obvious impending transition to ARM, which GraalVM is already preparing for.
In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.