To answer that, I'd like to know what it costs Apple (in performance, features, resources, and code base) to maintain Intel compatibility. Specifically, if Apple could design an AS-only OS:
1) Performance: How much more more performant (more responsive and stable), if at all, would an AS-only OS be?
2) Features: Are there features that Apple could offer on an AS-only OS that they can't on a hybrid OS? [Currently, there are some AS-only features on Monterey; that's not what I'm referring to here. I'm asking if there are features that Apple could offer on an AS-only OS that can't be offered, at all, on a AS + Intel OS.]
3) Resources: How significant would be the savings in person-hours?
4) Code Base: How much simpler and easier to maintain would the code base be? [This affects #3, but isn't exactly the same.]
The higher the costs are for nos. 1, 2, 3, and 4, the faster they will be to abandon Intel.
Quite right. But to give a rough idea:
1) I wouldn't expect quality/performance to increase appreciably with an AS-only OS, except in the sense that they can recoup effort that would normally go into x64 and use it to hold the quality bar higher. That said, I haven't seen many large companies actually do this. Generally savings get put into more forward momentum under the "evolve or die" mentality.
2) By your definition, I don't expect anything to be gained explicitly by going AS-only. There might be, but I would expect it to be minor.
3) Depends a lot on where engineering time is spent today. The savings are primarily in places like: not having to bug fix/deploy Intel drivers, reducing the hardware matrix, having fewer thread schedulers in xnu, etc. But it is clear that macOS is currently the only place in Apple that is spending time on
anything x64 specific. It also depends on if Apple truly abandons x64 internally, versus just keeping a light on in case things get weird in 10 years.
4) The OS itself won't gain a whole lot. There's places like the Accelerate framework, VideoToolbox, and the kernel, that have dependencies on x64 that could be removed. But the low level stuff is mostly C/C++, and the high level stuff is mostly Obj-C/Swift now. Apple's choice to lock CPU extensions behind frameworks is partly what makes a lot of this easier. In essence, Apple already paid the cost to architect it appropriately, and it's not a huge cost to leave things in place for the time being.
My take is that #3 is the biggest factor for Apple. Especially when talking about test matrices, driver support, and the like. Things are a little different today with the yearly releases compared to the Intel switch, so we could very well get a couple more macOS releases before they drop support in the OS.