I think the largest hurdle for ARM to get over is the preponderance of Windows installations with kernels only complied for x86. Linux and OS X (Mach) already run on ARM, and I think that possibly the NT kernel runs on ARM (Windows phone 7 is ARM, right?) I have trouble seeing Microsoft port over Windows proper to ARM until there's a really strong market for it. That being said, perhaps low power consumption ARM devices will provide that market. Perhaps this is another reason that Apple has their own ARM chip - to be at the forefront of the ARM revolution, displacing MSFT?
NT doesn't currently run on ARM (WP7 is still based on CE), though it was originally designed to be CPU independent. Probably the biggest obstacle for MSFT porting Windows to ARM is not the expense of the port itself, but reluctance to put out a version of Windows that's binary incompatible with all the Windows software out there.
Incidentally (and speaking of breaking compatibility), MSFT is working on a brand new kernel and operating environment (Midori) which does have ARM as a target. But this is an incubation project with no guaranteed release, though it's a very serious effort.
There is nothing in Windows which requires fixed endianness. While all known versions of the OS have been shipped on little-endian machines (except XBox 360, albeit running highly modified version of NT Kernel), there is very little dependency on the endianness for all modules except format parsers and network API. Changing that is a relatively simple undertaking, much simpler than building a new version of kernel, for XBox, for example
Alpha is most definitely not a bi-endian architecture; it's little-endian only. PowerPC chips can be either, but the vast, vast majority are big endian.
My point is that they went from zero apps and zero users to lots in 2-3 years. IMO the argument that Windows backwards compatibility is the only way to get the long tail of tens of thousands of apps has been refuted.
