Stuck on WP 7.x
I suspect the OEMs weren't willing to put in the effort - if it was even possible - to bring up WP8 on their old hardware.
Windows CE does not have a standard boot loader. It is up to the OEM to write their own boot loader, which calls directly into the OS 'Startup' function once it has located the image to run. The kernel is mostly supplied as shared source code and Platform Builder will build your code and link it to produce an image. See http://msdn.microsoft.com/en-us/library/aa446905.aspx for details (that's CE 5.0 rather than 6.0 but it's much the same on 6.0 and later versions). Dealing with interrupts, timers, power management and other basic hardware resources is a job for the OEM Adaptation Layer, often written by the processor manufacturer (as a Board Support Package) but the OEM can customize it. http://msdn.microsoft.com/en-us/library/ee479387(v=winembedded.60).aspx
The Windows 8 kernel expects to run in a PC-like environment. For ARM devices, it uses UEFI to boot and ACPI to describe the system hardware in a way that Windows can use to configure itself to the system. I can't find anything explicitly saying that this is how Windows Phone 8 does it, but the intro for Windows RT is here: http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx .
I can easily imagine that the UEFI and ACPI implementation is larger than the space available for the CE boot loader. It's likely that the various hardware in the device doesn't conform to the Windows-on-ARM models that would allow generic function drivers supplied by MS to be used, meaning that the OEM would have to write new drivers (the driver models are completely incompatible). It's a vast amount of effort that would mostly be wasted if new devices conformed to the Windows-on-ARM hardware model, and probably running a huge risk of bricking the old phones even if it could be achieved.
I can't see this happening again: I think it is very unlikely that any technical changes will now obsolete Windows Phone 8 hardware. The kernel is the same as on the desktop, the server and on Windows RT devices, and it boots and talks to hardware in the same way. Microsoft don't have a third kernel stream to use (excepting research projects like Singularity, or the .NET Micro Framework which is smaller still than CE). There's a much clearer and cleaner demarcation between MS-supplied code and OEM-supplied. The runtime is the same as the full .NET Framework, with the server pieces removed but otherwise the same.
The main programming difference between Windows Store for desktop/tablet and Windows Phone apps is that Windows Phone Runtime (WinPRT) still wraps up the Silverlight/WP7 UI controls, rather than using the UI controls developed for Windows Runtime. Windows Phone 8.1 'Blue' is basically held up waiting for that. My suspicion is that the Windows Phone 8 SDK was so late because they were trying to get it done for WP8, but couldn't make it work in the space/speed/time available and cut it at the last minute. There's not much point investing heavily in the apps with a shifting base underneath - or maybe all the changes to the apps were already done for proper-WinRT-on-WP and thus can't readily be back-ported to the old UI components?