TL;DR: If you're talking about just programs offered in the Software Center, and they are offered for both 32-bit and 64-bit versions of Ubuntu (which almost all are), then there are probably not any problems causing them to break specifically a 64-bit system.
Of course it's possible for a program to have a bug that prevents it from working correctly on some particular architecture. As the 64-bit version of Ubuntu is not new, and has not been new for quite some time, there's no reason to think that software provided officially through Ubuntu's official repositories (nor paid software, nor software installed through PPAs) is more likely to have 64-bit specific bugs than 32-bit specific bugs.
Generally speaking, anything that is available for your architecture in the Software Center has been tested on your architecture and is pretty strongly believed to work on it.
However, the situation may be different with respect to some third-party software. It's possible some vendors, especially of binary-only software, have spent inadequate time on the 64-bit versions.
The thing is, you can install 32-bit software on a 64-bit Ubuntu system:
Multiarch facilitates installing 32-bit packages on a 64-bit system. The 32-bit version of a package packagename
can be installed as packagename:i386
in APT:
sudo apt-get update
sudo apt-get install packagename:i386
It's possible to have conflicts between 32-bit and 64-bit versions of the same software. Such conflicts are the norm for programs, but are uncommon for libraries. Since dependencies required to be of the same architecture as the software requiring them are most often libraries, most often such conflicts do not arise.
If you have binary-only 32-bit software from a third party, it may depend on 32-bit libraries. But you can usually install those libraries (same technique as above) and then install the binary-only 32-bit program on your 64-bit system.
The main areas where a 64-bit system might be inadequate where a 32-bit system would work are:
Your computer is low on RAM. The 64-bit versions of programs (and the libraries on which they depend), as well as the data structures they create, tend to be somewhat larger and thus to cause more RAM usage when running. In practice, for systems with enough physical member, this effect is not usually very great. For systems with only just enough RAM, it can be considerable.
The software you need to run is not a program but a driver and the driver only has a 32-bit version. Then you might really be out of luck, and may have to use the 32-bit version (since a 32-bit driver requires the 32-bit kernel in almost all cases, and the 32-bit kernel can only run 32-bit programs, preventing any part of a 64-bit OS from being run).
Since most drivers are free open source software or are otherwise distributed (among other ways) as source code, and because 64-bit systems running the Linux kernel have been around and common for decades now, this is not very likely. But if you have obscure hardware with binary-only proprietary drivers that only come in a 32-bit version, this might demand you run a 32-bit operating system.
Like programs, drivers can also have bugs, including bugs that selectively affect a particular architecture. Since drivers are often lower-level (i.e., "closer to the hardware") than many applications in terms of their implementation, my guess is that architecture-specific bugs are more common in drivers than programs. However, there is still no reason to think such bugs would be more likely to appear on a 64-bit system than on a 32-bit system.