I could almost buy that you would benefit from a 64-bit kernel and 32-bit userspace more than you'll lose time discussing it. Which can, of course, sometimes be true (I do that for a redis server).
But if you want to start mixing 64-bit and 32-bit binaries as you mentioned in a comment, you're really looking for trouble. That would mean that a lot of libraries would be mapped twice in memory, which would be quite inefficient. No distribution offers that (even the Debian
multiarch project doesn't cover binaries).
You refer to binaries like "cat", "dd", "bash", even "gcc" as not needing 64 bits, but those are typical examples of programs where using 32-bit pointers instead of 64-bit ones will not save "anything". You already lost more time typing
cat in your message than you could ever save by running a 32-bit version of it instead of 64-bit.
Not to mention that
x86_64 doesn't only have bigger pointers, it also has twice as many generic registers, and compilers can make as many assumptions about available extensions as with
i686 (which is more than
i586, in turn more than
i486, in turn more than
i386). Performance can end up being measurably better.
If you want to use both 64-bit and 32-bit binaries, my personal recommendation would be to run the (likely very few) pointer-intensive applications needing less than 4GB of RAM and for which you truly care about performance in a 32-bit
chroot (or any container). Unless they're running on a Java stack, in which case you'll probably be better off sticking to a 64-bit userspace and use a hybrid JVM (with compressed pointers).
If you really want a 64-bit kernel and a 32-bit userspace, and not only because you read somewhere that it'd have a better performance, you can always take the kernel from the 64-bit packages of your distribution and squeeze it on a 32-bit install.