For the specific purpose of enabling CrossOver's 32-on-64 support and things like it.
It's not too hard for the kernel to support user code merely entering the processor's 32-bit mode. CrossOver's processes don't even use 32-bit system calls or 32-bit Mach-O binaries, so support for those could hypothetically be removed, except that most of it is needed for watchOS anyway. But the most significant cost of i386 support was in userland, not the kernel: building separate x86_64 and i386 copies of every system library, and supporting the legacy i386 ABI, including an older version of the Objective-C runtime ABI. That's all gone now.
eg. Maybe draw the boundary of where you thunk at a different place. Maybe do more translation in user mode as this wine project did. Or focus on binary compatibility with old, frozen-in-time frameworks instead of rebuilding them with every OS build. Obviously the specifics will vary with actual details of breakage. But from outside, it seems like these type of questions weren't pursued to their maximum extent, resulting in pain for the end user.
So the kernel switched itself in 32 bit virtual mode, though some parts of the pmap layer understood 64 bit page tables in order to manage the 64 bit physical address space. While the kernel could not see all of memory, it did not need to, it could map any apertures it needed in by manipulating its own page tables.
At that point it is pretty trivial to setup a 64 bit address space for a process. The kernel could not directly map all of virtual address range of the process at once, but it already had the pmap and aperture management code to deal with that. That decoupled 64 bit user space bringup from the 64 bit kernel port. The first release that supported 64 bit processes did not have 64 bit UI frameworks, just the C library and some low level posix functionality, but it allowed scientific code that benefited from more memory to run.
Support for 64-bit GUI applications on OS X didn't arrive until 2007, a year after Intel Macs started using 64-bit processors. Support for running a 64-bit kernel arrived in 2009, and only for machines that had 64-bit EFI firmware. In 2012, Apple dropped support for the machines that had 64-bit processors but used 32-bit EFI, so from that point on they were handling the 64/32-bit mix the same as other operating systems.
This is quite curious. Apple inconvenienced so many users by "removing" 32-bit support on Catalina, and then they added support for local descriptor tables? I'm not aware of any use of LDTs on modern systems (except perhaps Chrome for additional sandboxing).