No, the real problem is that Apple sometimes makes strange decisions. Too much functions follows design decisions. A lot also for economic reasons, to push customers towards certain products. Otherwise, there would be a Mac Midi, for example.
This can also happen with Apple's ARM-SoCs. The cooling system can be bad there as well.
There are many ways that Apple could mess up an ARM transition (too sudden, too expensive, form-over-function, locked-down, dumbed-down, buggy software, not actively working with key developers...) but, frankly, none of those mistakes require an ARM processor. Until we see what Apple actually does over the next year (I'm sure everything announced on Monday will sound... magical) all we can do is look at what is technically possible.
In
technical terms, there's no reason why all software that is still a "going concern" shouldn't get re-built for ARM over the next 12 months, and for modern software there's no reason why that should be a particularly onerous task c.f. the usual annual maintenance - assuming Apple does a competent job of making MacOS for ARM. Equally, there's no reason why MacOS ARM shouldn't have half-decent x86 emulation/translation facilities to smooth over the transition. This is MacOS we're talking about - not Windows - so it's not like users expect 20 year-old software to run, and the 64-bit switch just culled most of the "abandonware".
The unavoidable casualty is going to be running
high-performance x86 Windows software on Mac hardware - I'm sure that ways of running your tax software (or whatever) will emerge - even under full emulation, or via ARM Windows' built-in x86 emulation. As for Linux, the bulk of the big open-source projects already support ARM64. Docker etc. should be able to run either with an ARM Linux VM (MacOS has a built-in virtualiser which Docker for Mac already uses) or, potentially, with an emulated x86 Linux VM. Yes, the former will need Docker images built for ARM, but that is already a "thing" - and those images are mostly compilations of open-source software that already builds for ARM. The latter - well, if you're developing and testing server-side stuff - no GUI, or the GUI runs on the client, and your testing only uses a fraction of the software's capacity - will x86 emulation be so bad? Will it make a practical difference to your workflow if the container is running on a virtual server in the cloud (or a PC tucked in a cupboard somewhere)?
Sure, that won't happen if Apple turns the Mac into a locked-down clamshell iPad running a castrated version of MacOS - or if they junk the entire Intel mac line on Monday forcing you to "upgrade" as soon as your trusty 2012 MacBook fails - but let's see what they do.