There is no guarantee that a 32-bit application won't get installed into
Program Files, or 64-bit into
Program Files (x86). Firstly, users can override that manually with most installers, and secondly, some applications/installers are not coded according to MS specs and may get installed in the wrong place (most often the
Program Files path is hardcoded, so a 32-bit app ends there, I don't think 64-bit app would end in
(x86) folder by a simple mistake like this).
This separation is hardly useful IMO, it just allows you to have a 32-bit and 64-bit app installed into identically named folders (such as
jre7) regardless of their architecture.
Only you can know whether you need a 32-bit and 64-bit version of the same application. Sometimes a functionality is not available in 32-bit or 64-bit version (eg. if an application uses a plugin which is a 32-bit DLL, it cannot be used with 64-bit application, and vice versa).
Speaking of Java, the situation is more complicated:
Firstly, if you have a Java application that calls native code and does not provide a DLL for both versions, you need to use the corresponding JRE. Period.
Secondly, although 64-bit JVM allows you to use much more memory, it comes at a price. A reference (pointer) takes 4 bytes in 32-bit JVM , but 8 bytes in 64-bit JVM. Since Java applications use so many references in general (everything is an object, right?), going 64-bit increases memory requirements significantly, by some 50%. Java actually mitigates this and uses compressed pointers when possible; compressed pointers take only 4 bytes, but need some decoding when actually using them, so there is a slight performance penalty instead of the memory overhead. See
this article on HotSpot Performance Enhancements.