I would imagine it might actually be an indication that some ARM-based Macintosh models are on the horizon since they dropped 32-bit on the ARM side a while back.
Apple killed 32Bit arm in the A11 and as a result gained extra space on the chip for more cores and the Neural Processing module. It’s highly expected that they will eventual build ARM Macs and that can’t happen if 32Bit software is common.
I can't see how the two things might be related. You still have to recompile everything when moving from x86 to Arm, and in general code that has issues moving from 32 bits to 64 it's because it's full of 32 bit assembly (which would be rewritten in order to move to Aarch64) or it does nasty stuff like storing pointers in 32 bit integers (instead of using uintptr_t and the like).
I can't really see any extra complexity arising from doing x86→Aarch64 instead of x86_64→Aarch64. I think they are doing step to force people to rebuild old apps, so that
1. They might consider providing Apple a Bitcode™ representation that they can use in the future when switching to Aarch64;
2. They get rid of all those old nasty Carbon apps;
3. They kill the viability of older third party tools, such as Wine on macOS (which will be either forced to switch back on using X11 + providing 32 bit Darwin libraries, or writing an insane amount of thunks), further pushing people towards either rewriting old apps with SwiftUI or Electron (both alternatives that would make the ARM switch quick and easy)
Apple killed 32Bit arm in the A11 and as a result gained extra space on the chip for more cores and the Neural Processing module. It’s highly expected that they will eventual build ARM Macs and that can’t happen if 32Bit software is common.