On 32 vs. 64 bit applications
I worked on the KSR 64-bit supercomputers circa 1992. Simply converting most applications from 32 to 64 bits generally hurts performance, depending on the architecture of the hardware. If 32-bit reads and writes are reasonably efficient, then you can adopt a C programming model where "int" is 32 bits and "long" and pointers are 64 bits and not suffer much of a penalty; on the other hand, that usually has a hidden penalty in the hardware which handles halfword memory writes, which slows down full 64 bit mode. That might be a reasonable tradeoff for a consumer machine, rather than for a dedicated supercomputer; I don't know which way the 970 goes on that. The "I32LP64" model tends to upset a lot of poorly-written C code, due to inappropriate assumptions about the sizes of data objects.
There are some very specific application domains which can greatly benefit from a 64-bit integer size. Some cryptographic algorithms benefit from being able to do logic operations in 64-bit chunks (of course, many algorithms are designed not to need 64-bit arithmetic, and wind up not benefitting if it's available). It also turns out that the TCP/IP checksum benefits from wide word widths, even though it's technically defined as a 16-bit ones-complement sum. And it turns out there's a lot of perfectly ordinary code (filesystems, network protocols) which has been written assuming that 64-bit integers exist in order to simplify writing the code, at the cost of complicating the compiler's job; throw a 64x64 multiply in an inner loop on a 32-bit machine and you can seriously slow an application down -- in a way that real 64-bit integers can positively affect.
The leap from 16 bits to 32 bits was an important one, because there is a huge array of problems interesting to typical computer users which need data sets bigger than 65536 bytes. (*) There are scarcely any applications with an urgent need to address more than 2 gigabytes of RAM, and relatively few which could even sensibly use even that much memory. However, no doubt new applications will be found once developers can count on even cheap systems having 8GB or so (and of course we can always count on programmers' laziness to bloat just about any software

).
(*) I can remember the flame wars between Intel supporters and Motorola supporters back in the mid 80s, where very carefully chosen 16-bit 8086 programs would run faster than equivalent "32-bit" 68000 (**) programs -- as long as you kept the data set small enough that it would run at all, of course.
(**) And of course, there were the endless discussions about whether the 68000 was "really" 16 bits, 24 bits, or 32 bits. Or 16/32 bits. Fortunately, the mighty 68020 made all those arguments moot.