The question you're asking isn't new to me. I've had a few upper level IT ask me the same thing and I'm just a freelance student doing mostly hardware cleanup and recovery. I can see the logic here, so let me try to explain it to you.
First, when you roll out an app, no matter what the actual functions are, you have to target the installation in a way that makes it versatile or you'll get nothing but complaints about not being able to install in certain ways. Yes, the viewer is 32bits, but you can install it anywhere you want, technically. Just because windows loads a program from a location doesn't mean that it will run in a specific kernel. The locations are there to prevent confusion, yes, but not everybody puts things there anyway, so you do have the option to put the install where you want. I've run the play app from a usb flash drive, it makes no difference, except for the speed at which it loads.
The other logic here is that they want to keep all files in the same location to simplify software removal or upgrade later. It's easier to grab the top level location and work your way down when you only have one top level folder, and it's faster to upgrade. I've done benchmarks that prove that even on the same SSD with a basic windows 7 system, and one app installed, splitting the files up slows it by half. In other words, keeping the software in one place allows it to be upgraded or removed at twice the speed. Why does it install to an x86 folder? The main interface is still 32bits, and many low end business machines are still using 32bit windows to function efficiently. This allows VMware to function in both environments, having a dual install in a single installation. It's faster to install, and to develop when you can leverage the power of the lower end on operations that don't require the registers of the higher. It's also easier on system resources. Ops that take up 8mb or more memory on a 32bit can often take 12 to 16 on 64bit, especially if you use any higher resolution visual displays. Keeping the visuals for the opening app to 32bits allows them to run in a 64bit space through WoW (the kernel extension that runs 32bit apps). They do run slower, due mainly to the overhead of altering the memory space, but not by much. Basic User Interface elements actually have almost no noticeable difference at an i3 dual core, a slight difference on an i5, and only a second or so on an i7 (dual cores all). With a quad core it is more noticeable after you've tried native 64bit interfaces.
All that said, Why is it going to an X86 folder? Because you told it to, genius. You should still have the option to put it wherever you want. I've installed it to external drives, you just have to tell the installer to put it there. Older apps didn't allow this, as they were trying to maximize on the external files they needed being on the same drive and the lack of threading meant it was faster to read the files from the same drive in a tape-drive-like fashion, as they were needed. But with threading, and partitioning becoming evermore popular, that has changed. Installing to drives other than the main drive can sometimes increase the speed at which programs run, especially when they can read the files in a threaded fashion, almost simultaneously.
Another option:
Once installed, put a symlink to it in the x64 program files folder. This will allow you to find it there. I do this with every single app I install, then I can get to it from that folder. In windows, they call it a hardlink, which refers to mapping a pointer to a hard drive location, rather than using a shortcut. Shortcuts still have to run through the OS layers before they get to the drive location (translating the drive letter to a physical drive and all that). A hardlink goes right to the drive. I then redo shortcuts that use the link rather than the actual placement.
Option 3: install it, then move the folder, and update your registry by hand. I don't recommend it, but it does work.
