You need that code anyways for every resolution, and it means you need only n paths for n different resolutions, not the n×(n-1) you need for switching from any of them to any of the other ones. It also makes handling the various setups completely independent. There can’t be some left-over state from the previous resolution setting that interferes With how the current setting works.
It also might be a left-over from CRT days, when the hardware couldn’t seamlessly switch to a different clock frequency, and doing the full restart on the software side didn’t make much of a difference (yes, lots of hardware could switch horizontal resolutions even on a line by line basis, but that, AFAIK, always was on the same number of vertical lines and frames/second, and, using ratios between horizontal resolutions with small denominators such as ½ or ¼.
This is one of those things where it takes a company like Apple to not only notice that can be improved, but also decide it’s worth spending resource on.
We also know that Apple spent time optimizing very specific operations in their CPU - optimizing retain/release operations on objects is the one that’s gotten mentioned a lot. Maybe they spent similar time optimizing things in the GPU for changing modes/outputs?
MacOS sends a notification to each app that the screen size changed, so fast CPUs speed that up. Lots of cores can process those notifications in parallel.