Good reasons to keep 32-bit Microsoft Windows desktop OSes
Solution 1:
32-bit can be slightly faster in certain use cases -- the smaller addresses means sightly more compact code, which means greater cache efficiency. In the benchmarks I've seen, that efficiency tends to be be overshadowed by 64-bit's greater computational efficiency in heavy-computation environments. But 32-bit does in fact occasionally win on some benchmarks. YMMV. The age of your software matters, as newer builds take advantage of 64-bit stuff that older builds do not.
More compact code means less disk space. Just go download the ISOs for your favorite OS in 64 and 32 -bit flavors to see the difference. It's not trivial. It's also quite a lot more once you uncompress the binaries. As pointed out by OrangeDog: Much of this space consumption comes from the fact that 64-bit OSes ship 32-bit libraries in addition to the 64-bit ones.
You still get better compatibility with legacy components and software with 32-bit. This is particularly visible in systems that dynamically compile on the host machine but pull in 3rd-party binary libraries at the same time. Microsoft's .NET framework is a great example of this: while the programs are theoretically architecture-independent, anytime you link to a native binary you tie to one arch or the other. Many developers don't even know this is happening, and ship production components that will fail to run on 64-bit systems without some tweaking to explicitly instruct .NET to run in 32-bit mode. Most people don't know how to do this.
As pointed out by Daniel B: Windows .NET development on 64-bit machines leaves you open to a frustrating inconsistency where under certain circumstances exceptions are masked by the OS.
Legacy hardware. You can't run a 32-bit driver on a 64-bit kernel.
None of this adds up to a show-stopper for most people. Still, you have to decide how these factors affect your environment.
Solution 2:
The only reason I can think of to keep a 32-bit desktop operating system is if you use old 16 bit (e.g. DOS) programs and you do not have the windows version which supports Windows Virtual PC.
(And even then I would install a 64 bit OS and use something like DOSbox).
Edit: There actually is another reason: Hardware which fails to cope with more than 4GB address space. E.g. FireWire trying to do DMA. Or any (old) hardware with no 64 bit drivers.
Solution 3:
Anything that will run Windows 8 is already 64-bit capable, unless you happen to have some first-generation Intel Atom netbooks (and I doubt that very much). That's about the only thing I can think of.
AMD released its first 64-bit capable Opteron in 2003; and since then virtually every processor they have made has been 64-bit capable.
Intel was a year later, releasing its first 64-bit Xeon (Nocona) in 2004, and expanding to just about the entire product line by 2006. Aside from the aforementioned early Atom chips, every Intel processor today is 64-bit.
Wikipedia has a broken down processor list if you're interested in ancient history.
Solution 4:
Compatibility with Ancient Software/Hardware.
If everything works under x64, I wouldn't bother with 32 bit.
Solution 5:
Memory addresses in a 64 bit machine naturally take 64 bits. Those same addresses take 32 bits in a 32 bit machine. Under some pretty exceptional circumstances, that "increase" in needed number of bits can be the difference between good performance and poor performance on a memory limited machine.
Beyond that, since you are likely to be running 32 bit software on a machine that could be running 64 bit software anyway, and 32 bit support works reasonably well on 64 bit machines, the differences on the hardware side are not game changing. Occasionally you will find a legacy device that doesn't have a 64 bit hardware driver, but that is now very rare due to 64 bit operating systems being available for over a decade.
One point to consider is that many older 32 bit applications are older in many ways beyond their bit-ness. On the windows OS side, a 32 bit app might get confused if it is looking for files in "Program Files" that are now located in "Program Files (x86)". Certain registry items likewise might need manual attention. Again this is more a function of slightly mis-written applications that now need your help to "find" things that would have "just worked" if the machine happened to be 32 bit.