If you run into this it can:
1. take a while until you aware there is a bug (as it likely only happens spurious potentially with different effects every time)
2. take quite longer to somewhat pin down
3. And if you have not atomic experience and the bug is in a library might be outside of your skill/payment level to fix requiring major rewrites. And all of this parallel to all the other work you have to do.
=> While this should be rather easy for many app for some it might be a nightmare which is combined with the regularly planed work might very well take many month, after customers start using it and run into the bug.
Ah, so just like the Catalina 32-bit Armageddon.
Uuuh, but they have a track record of terrible developer support, so I don't see this actually happening.
As a developer there is a nuisance of one more damn thing to test, but compared to the nuisance iOS developers go through to make sure it looks nice on all the different sized devices, testing on an ARM before release isn't bad.
Having developed through the 68k-to-PPC and the PPC-to-x86 and the x86-to-amd64 days I think I can safely say I never had a problem with any code in a transition¹². There are developers that will, if you have written optimized vector code or some such and you care to also be highly performant on the ARM you will be spending resources to make sure you map onto whatever the hardware provides, but you've been doing that for the various Intel instruction set changes anyway.
␄
¹ I'm not saying architecture doesn't matter, doing early ARM porting for Debian I can tell you having C "char" be unsigned was a huge pain in the codebase. But Apple has control top to bottom and has every incentive to make it easy for developers, if only for themselves.
²At least not any problems bad enough to leave a mark on my memory. I'm sure I had to learn about intptr_t sometime after it was invented and probably learned a lesson about size_t at some point.