From a purely anecdotal perspective, I've noticed a vast decrease in the performance of the macOS updaters/installers since the point when they switched to using what is essentially the iOS mechanism for them, with the MobileAsset UpdateBrain stuff, and .ipsw files, and chunked pbzx archives nested inside zip archives nested inside xar archives. I don't remember the details of the previous system, but I remember it seeming a lot simpler, a lot less buggy, and certainly a lot faster on my hardware.
I’m still kind of confused why they don’t have a a/b update system for macOS now that Sealed System Volume is a thing. I feel like one of the major benefits of that would be that you can swap /System out and not worry about losing any user state, so why can’t they just download a new System volume, put it somewhere else (while you’re using your computer), then on reboot boot from the new one and throw away the old one? If you disable SSV then they can use the slow update process.
(Unless there’s too many system files that are updated a lot and not sealed?)
I'm trying to think how you could reliably, securely hash one volume while running a potentially untrusted system from another volume. I imagine this can be done, but I'd be guessing as to how. For now, I suspect Apple has thought this through and has determined that booting the system into a known-cryptographically-clean state is the best method at hand for reducing the risk of a compromise/failure in the process of signing the system volume.
FWIW, APFS snapshots do at least provide an instant rollback mechanism, whereby a failure to install and sign the updates to the new temporary snapshot do not destroy the previous system. So what you describe seems reasonable and potentially feasible.
The "brain" to which it refers (on x64 machines) basically is an iOS device (running a variant called bridgeOS) on an ARM coprocessor (T2) inside your computer. Same secure boot, same TSS signatures, etc.
