I guess they have some ISA flexibility (which is remarkable). But not much; each transition was still a very special set of circumstances and a huge hurdle, I'm sure.
As in, most of the work occurs in the low-level parts of the Operating system. After that the OS should abstract the differences away from User-space.
First of all: there's lots of software that's not the OS. The OS is the easy bit: everything else: grindy, grindy horrorstory. A lot of that code will be third-party. And if you think, "hey, we'll just recompile!", and you can actually get them to too - well, good luck, but performance will be abysmal in many cases. Lots and lots of libraries have hand-tuned code for specific architectures. Anything with vectorization - despite compilers being much better than they used to be - may see huge bog downs without hand tuning. That's not just speculation; you can look at software that's gets the vectorization treatment or was ported to arm from x86 poorly - perfomance falls off a cliff.
Then there's the JITs and interpreters, of which there are quite a few, and they're often hyper-tuned to the ISA's they run on. Also, they can't afford to run something like LLVM on every bit of output; that's way too slow. So even non-vectorized code suffers (you can look at some of the .net core ARM developments to get a feel for this, but the same goes for JS/Java etc). Webbrowsers are hyper-tuned. regexengines, packet filters, etc etc etc
Not to mention: just getting a compiler like LLVM to support a new ISA as optimally as x86 or ARM isn't a small feat.
Finally: at least at this point, until our AI overloads render that redundant - all this work takes expertise, but that expertise takes training, which isn't that easy on an ISA without hardware. That's why Apple's current transition is so easy: they already have the hardware; and the trained experts some with over a decade of experience on that ISA!. But if they really want to go their own route... well, that's tricky, because what are all those engineers going to play around on to learn how it works; what's fast, and what's bad?
All in all, it's no coincidence transitions like this take a long time, and that's for simple (aka well-prepared) transitions like the one's Apple's doing now. Saying they have ISA "flexibility", like they're somehow interchangeable is completely missing the point on how tricky on those details are, and how much they're going to matter on how achievable such a transition is. Apple doesn't have general ISA flexibility, it has a costly route from specifically x86 to specifically ARM, and nothing else.
The vast majority of the code written for any given computer or smartphone doesn't have this level of sophistication and optimization though. I'd wager that for most code just changing the build target will indeed mostly just work.
It won't be painless but modern code tends to be so high level and abstracted (especially on smartphones) than the underlying ISA matters a lot less than in the past.
Also - why would Apple massively up and change uArchs? Even if they did decide to turn Apple Silicon into not-ARM, I'd wager it would look a lot more like ARM than for example, x86 does.
This isn't a question of precise instruction timing, it's a question of compilers being pretty bad at leveraging SIMD in general, even in 2020. Also, while I'm sure lots of projects have hand-tuned assembly, even higher level stuff like intrinsics help a lot, and need manual porting.
Also likely the small tweaks they will want from time to time should be "easy" to follow internally, if you can orchestrate everything from top to bottom and back.