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 off course can 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 than you could ever save by running a 32-bit version of it.
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 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 it's 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.
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 one from sources whichever distribution you use.