It's true that your "just about" makes your statement true when taken literally. However, I would maintain that the implied meaning of what you said varies significantly from the literal truth of what you said. It's similar (although to a far lesser extent) to saying that just about the only thing a car is good for is protecting you from lightning strikes during a thunderstorm. In the case of LDView, the main gain you get when running the 64-bit version under Windows is the increased performance, not the larger memory space.
Very few LDraw models are large enough to cause 32-bit LDView to crash due to using more than 3.5GB of memory. (In Windows, a 32-bit program can be compiled to use roughly 3.5GB of memory. If the program is run on a 64-bit copy of Windows, it automatically gets this extra space above 2GB if the option was enabled during compilation. If the program is running on a 32-bit copy of Windows, this only happens if Windows itself is configured to allow it.)
On a side note (not meant to add further disagreement to your statement, but to hopefully add useful information), I have discovered after porting multiple programs to 64 bits that doing so often uncovers previously unknown intermittent bugs (things like uninitialized variables and off-by-one array overflows). Where the 32 bit version might almost never behave wrong due to a given bug, the 64 bit version might always crash, or very frequently crash. So porting a program to run both in 32 bits and 64 bits can in fact improve the overall quality of the program.
Very few LDraw models are large enough to cause 32-bit LDView to crash due to using more than 3.5GB of memory. (In Windows, a 32-bit program can be compiled to use roughly 3.5GB of memory. If the program is run on a 64-bit copy of Windows, it automatically gets this extra space above 2GB if the option was enabled during compilation. If the program is running on a 32-bit copy of Windows, this only happens if Windows itself is configured to allow it.)
On a side note (not meant to add further disagreement to your statement, but to hopefully add useful information), I have discovered after porting multiple programs to 64 bits that doing so often uncovers previously unknown intermittent bugs (things like uninitialized variables and off-by-one array overflows). Where the 32 bit version might almost never behave wrong due to a given bug, the 64 bit version might always crash, or very frequently crash. So porting a program to run both in 32 bits and 64 bits can in fact improve the overall quality of the program.