Just to be clear (as I wasn't sure from your post whether you understood this point) - A processor running in 32 bit mode (on Linux) has a per process virtual address space limit of 3GB. Note: per process. In other words, the 4GB addressable space (3GB user + 1GB Kernel space) is for each single process, not the whole machine.
So if you had a machine with 32GB of physical RAM installed, and that machine happened to be running 10 heavy duty processes, each of which required 3GB of memory... that machine would happily run, and be utilising all of its RAM even though it is only running in 32bit mode!! In fact in this configuration it wouldn't even need to use swap! I just thought I should point that out because lots of people think that 32bit mode means a maximum of 4GB RAM useage over the whole machine, and that simply isn't true. It is the memory management module that needs to be able to address more than a 32bit physical address space (and they easily can), not the CPU's address bus itself. The CPU works within its 32bit virtual address space for the process that happens to be paged in at the time. The MMU then translates these virtual addresses into the physical addresses in the much larger (than 32bit) physical address space. Each time the CPU performs a context-switch from one process to the next, the MMU selects a new set of address translations appropriate for all the physical pages that the new process is using. This gives the appearance to the CPU that the 3GB space the previous process was using has just been removed from its universe, and a new 3GB data/code set suddenly appeared in its place, using the same addresses. (BTW, this is true of Windows machines, too, they work in the same way)
The point of all this is, the limitation is 3GB per process, and if you run top, you will see that the only process that tops even 1GB is DCERouter (because it also contains all the plugins). All the other processes are tiny. In fact a 3GB process would be extremely unusual.... certainly not anything we are likely ever to see in LinuxMCE. Perhaps if the process was a database engine and was caching a huge amount of the DB, or was a very heavy data processing/crunching application. But seriously unusual. And those types have a genuine need for 64bit processing.
BTW, all the CPUs we are talking about (Intel, AMD, etc) are 32/64 bit CPUs... anything you buy that is designed for Windows is going to be "i386"-style architecture as that is all Microsoft support and all of these are 32/64 bit.... Just because you see a CPU that describes itself as 64bit doesn't mean it isn't also 32bit... it is! The only 64bit-only chips are way outside what we are talking about (for Linux and Windows) such as the Itaniums and PowerPC, etc. This isn't going to change anytime soon, after all, we still have legacy 8 and 16 bit stuff! I agree with Thom, the sooner the world makes the break that should have been done decades ago, and dumps this seriously hamstringed architecture the better! Who remembers segmented address spaces?? urgh, and we still have legacy stuff for that!!!