For starters, you should know that there are essentially no proprietary applications for a 64-bit Linux desktop. Google, Adobe, iD, Skype, and the rest of the independent software vendors (ISV) who release Linux binaries of their apps by and large do so solely for 32-bit Intel architecture only.
Free software is a little trickier on a 64-bit Linux box, too. Now, I'm not talking about faulty distribution-supplied packages; the vendors that supply 64-bit versions of their distro generally live up to the words supported platform (although cutting-edge stuff like Compiz comes to i386 first).
But no one survives on distro-supplied packages alone. All of us download and install third-party applications. One of the things I enjoy most about the free software world is that every day I discover some new and interesting project.
Take a step back and consider your own system: how many locally-installed packages do you acquire over the course of one distro release cycle? For most of us, it is quite a few. If you run a 64-bit Linux system, this is going to demand additional overhead time on your part -- either maintaining a 32-bit compatibility environment, or compiling everything from source.
Whichever route you prefer, expect to run across more bugs and hang-ups than you would in a purely 32-bit environment. You are likely on a different platform than the developer, and no matter how good free software is, there is still the occasional lapse in judgment (assuming pointer sizes, for instance) that you will be the first to catch.
All the 64-bit distros have their own AMD64 forums to deal with problems unique to the platform. The second-string status of 64-bit is a big enough issue that Ubuntu even has a dedicated forum thread just for listing what applications don't work. Again, no big deal for some users, but worth a warning to others.
64 != 2*32
Limiting our discussion to distro-provided software, there are still a few myths about 64-bit computing to dispel. No, 64-bit application binaries are not twice as large as 32-bit binaries. You do not need to purchase a larger hard drive. Running processes may occupy a little more RAM due to larger pointer sizes, but far from double.
Conversely, 64-bit binaries are not twice as fast, either. You are unlikely to notice any discernible speed difference, particularly with desktop apps. Of course, one of the primary advantages of 64-bit Linux is the ability to load your system up with north of four gigabytes of RAM -- and if you do that, things will run pretty smoothly.
But the fact remains that the real performance benefits of 64-bit computing are not found in day-to-day applications. Addressing enormous chunks of memory, working with gargantuan databases -- these tasks are still primarily in the domain of servers.
For the rest of us, running a 64-bit Linux distribution is a matter of choice. We want to see what breaks, we want to try what's new, we want to work (just slightly) outside of the box. And if you are willing to live with the shortcomings described above, more power to you.
... on the other hand ...
That said, it really irritates me when I hear someone criticize "Linux" for those shortcomings. Yes, there is no Flash plugin for 64-bit Linux, and yes, Wine is a nightmare. But don't fall into the trap of blaming this misfortune on Linux. It is the individual fault of the various ISVs, not the not of the kernel developers and not of the distros.
And there is essentially nothing you can do to change this. Even the free-software-friendliest ISV is unlikely to adopt additional processor architectures to convenience a fringe constituency. Certainly being treated as a second-class citizen in this way makes 64-bit Linux less useful, but the decision behind it is not the kind that can be swayed by lobbying.
To boil it down even further: Linux runs great on 64-bit processors. The deficiency lies in the apps. Tell their developers how inconvenient it is.