"why we can't have 32, 16 and 8bit software running"
That partly depends on the CPU, and part depends on the OS support for old APIs and CPU modes, as applications are written to depend on a given CPU mode/instruction set, and OS APIs.
For example to run 16 bit DOS applications you need to emulate how the CPU works in real mode, and the OS has to make available the various DOS API calls (i.e. the "INT 21" calls) and the expected ABI.
To run 32 bit applications you need the CPU in a 32-bit compatible mode (so it won't, for example, use addresses and structures a 32 bit application can't manage), and the 32 bit API - because in the newer 64 bit one many parameter will have changed size.
Windows still run 32 and 64 bit applications. 32 bit version of Windows can still run 16 bit applications - that support was removed in 64 bit versions because when the CPU is switched to 64-bit mode it can no longer support the "Virtual86" mode which is used to simulate a real-mode CPU, so the old "subsystem" no longer works.
The 16 bit support could be added as a full software emulation - slower but given the increase in power since the 8086-386 days noone would notice, I guess, but there's no business incentive to add it (you can use a VM, anyway).
Same for 8 bit support - you could emulate many 8 bit CPUs and their OS in software (and emulators do exist), but there's little need to run CP/M application directly today.
The difference between Microsoft and Apple is the former know it has a lot of customers running old applications which may be used to perform critical tasks in factories, hospitals, etc. which may not be easily, cheaply and quickly rewritten. Crippling them will be a huge issue and a big damage to MS reputation.
Apple knows its customers base is totally different, and can tell them "64 bit or else" without losing money or reputation.