In the mainstream Linux-based distro's, the amd64 version is completely on par with the x86 one, so as far as software availability goes, you have nothing to fear either way (a few obscure platform-specific hacks aside). Also, it is possible, albeit with some severe hacking, to run 32-bit code on a 64-bit kernel, so if you absolutely have to, there are probably ways to make that happen. And if all else fails, you can always install a 32-bit virtual machine to compile for that particular architecture.
CPU-performance-wise, there isn't much difference either way: some applications benefit from 64-bit operations (typically, these are applications that have to deal with large integers and such); others don't get any benefit and might even run a tiny bit faster on a 32-bit kernel, especially if they need to handle a lot of natively-sized integers or pointer (which take up twice as much space on a 64-bit platform).
However, if you want to use more than 4 GB of RAM, 32-bit kernels do carry a real performance penalty, because you have to use PAE to make it happen.
As a general rule of thumb, these days I'd say go with 64-bits, unless you have strong reasons not to, most notably:
- you are using 32-bit libraries that you cannot recompile to a 64-bit platform (e.g. because you don't have the sources)
- you need to use a package from your distro that isn't included in the 64-bit distribution and cannot be installed from other trusted sources
- you are short on physical RAM (many programs use significantly less RAM on 32-bit systems, and 'short on RAM' invariably means 'less than 4 GB')
- you are coding for 32-bit production systems (you want to eliminate as many differences as possible; for example, PHP's
ip2long function has a nasty gotcha that only shows on 32-bit systems)