There is such a thing as technical debt. Apple couldn't have gotten so much performance with Rosetta 2 if it had to support 32-bit code. By dropping 32-bit support a year before the transition, they forced everyone to drop their last vestiges of old code. When the ARM transition then happened, it was smoother for everyone.
That you have to call this approach a mental illness is poor criticism.
Rosetta 2 does support 32-bit code - it’s used for running WINE.
macOS doesn’t ship a 32-bit version, because the 64-bit version on every platform is much faster and more secure, and shipping both would be twice the disk space.
(More secure because you can do so many tricks like PAC with those spare bits in every pointer.)
wine32on64 is used to translate x86 Windows APIs to x86_64, WINE translates these to x86_64 POSIX, and then Rosetta 2 translates these to aarch64 POSIX.
or maybe they could have just said, 32-bit programs will be slower...
Technical debt is when people make a mess, its perfectly possible to clean that mess without breaking ABIs. Particularly in OS's where the ABIs tend to be decoupled from the underlying code by abstraction layers. For example you can swap the filesystem in use and still maintain the behavior. Linux's syscall ABI has been basically static for decades, its only the userspace layers that don't try and adhear to those levels of compatibility.
PS: We like to give apple all this credit for having a "fast" machine, but the real question should be, if it can't solve the problem I have, does it matter how fast it is? Mac's for the vast majority of the people I see using them are basically trendy chromebooks, where the users are spending 99% of their time in safari. So its probably a good choice for apple if that is the user base they are interested in.
You run them in a virtual machine running an older version of the OS, the same way you do with legacy Windows apps that won't work on modern versions of Windows.
Which is overwhelmingly terrible compared with native. It seems there is a never ending set of copy/paste, window resize with multiple monitors, etc problems.
And it only works when your application doesn't have HW requirements that can no longer be met. Or the company in question just doesn't provide drivers anymore.
Frankly, the driver thing is somewhat understandable, but as you point out its easy to bolt software compatibility layers on, why the OS vendor can't manage to make it work well/transparently is a mystery.
That you have to call this approach a mental illness is poor criticism.