Es fiel mir bei Slackware 13.0 vs. Slackware64 13.0 auf x86_64-Architektur auf. Da das aber schon eine Weile her ist, habe ich keine Details mehr. Wenn bei der Portierung von ia32 nach x86_64 aus 32-Bit-Variablen 64-Bit-Variablen werden, steigt zwangsläufig der Speicherbedarf.
Letzteres trifft primär nur auf alle Stellen zu, an denen Zeiger verwendet werden. Das betrifft je nach Komplexität die internen Strukturen des Programms und zu einem kleinen Teil den Stack jedes seiner Threads, wo Rücksprungadressen auch in 8 statt 4 Byte Größe abgelegt werden.
Eigentliche Zahlwerte (z. B. "int" oder "uint32_t" in C) bleiben in den meisten Fällen 32 Bit groß, ebenso codeinterne Referenzen, die auf x86_64 meist 32-bit-relativ vom Compiler ausgedrückt werden, da das übliche Programm nicht mehr als 2 GB reinen Code am Stück hat (bzw. wenn, dann dieser in viele Bibliotheken modularisiert ist).
Der Speichermehrverbrauch unter Linux hält sich jedenfalls definitiv in Grenzen und ist kein ausschlaggebender Grund, mit 3 GB (solange man damit nicht schon nahe an der Grenze des von der Hardware in Beschlag genommenen Adressraums stößt) noch 32-Bit-Kernel + -Userland zu fahren, wenn man ähnlichen Speicherdruck auch mit 4 GB RAM hätte (z. B. durch den allseits beliebte Speicherfresser, den modernen Browser), aber dann kein Problem bei einem späteren Upgrade hat.
Als Sonderfall gibt es auch noch die Konstellation "64-Bit-Kernel + 32-Bit-Userland", welche nicht nur bei manchen Recovery-Linux-CDs zum Einsatz kommt (man muss dann nur zwei verschiedene Kernel anbieten, je nachdem, ob man z. B. Chroot in eine 64-Bit-Umgebung ermöglichen will), sondern auch auf Produktivumgebungen als "x86_32"-Plattform (streng genommen kein "wahres" 32-Bit, da damit z. B. von den zusätzlichen AMD64-Registern und SSE2 Gebrauch gemacht werden kann) angeboten wird, da z. B. PostgreSQL ein Multi-Prozess-Modell verfolgt, mit dem auch mit 32-Bit-Code problemlos mehr als 4 GB RAM verwendet werden können.
Auf Windows sieht das minimal anders aus – durch die weite Verbreitung von 32-Bit-Anwendungen müssen außerhalb kontrollierter Umgebungen (Windows PE standardmäßig ohne WOW64) ständig auch zusätzlich 32-Bit-Bibliotheken geladen sein.
EDIT: Neben anderen Dingen (frühere Popularität von 32-Bit-Plugins; JIT-Javascript-Compiler, die ursprünglich nur 32-Bit-Code erzeugen konnten) ist das auch ein Grund, warum alternative 64-Bit-Browser so lange gebraucht haben, sich auf Windows/Mac durchzusetzen: Das Konzept "Pointer auf Pointer auf Pointer von Pointer" ist eine beliebte Implementations-Krankheit von VM-Programmiersprachen.
