Payloads are generally hardware independent (but there may be bugs lurking). Payloads typically aren't the problem when it comes to software freedom.
You pick them by your needs: If you want to boot a "normal" PC operating system, SeaBIOS is the easiest way to go, since it implements the interfaces that they all expect. If you have any special needs, the other payloads might be closer to what you need, or you can build your own.
There are two "freedom" issues in coreboot itself:
Intel is uncooperative in the free firmware space. Google worked around that by creating an independent binary from Intel's code and then making coreboot work with that.
Intel now followed suit and provides such a binary themselves (see http://www.intel.com/fsp).
The above quote is misleading: The problem isn't microcode, it's x86 binaries for RAM initalization and firmware for the Management Engine, a companion processor without which the system isn't really functional except by employing a hardware hack (which reduces power management capabilities).
Hardware requires all kinds of additional code or data for initialization. This can be microcode updates for the CPU; firmware for additional microcontrollers, some of which are integrated in the chipsets these days; tables for board specific information like calibration data.
You can bypass some of these binaries and the system will continue to boot (eg. some CPU microcode updates); for others, the absense will lead to reduced functionality, such as no XHCI (and thus USB3) on AMD chipsets without the XHCI firmware; and some binaries will lead to an unbootable system if left out, like the Management Engine on Intel chipsets or CPU microcode updates on some CPUs that come with such faulty microcode that they don't even get through the boot process.
coreboot has a "blobs" repository to keep those things separate, but microcode and some other minor binaries reside in the main repository for historical reasons. There are plans to change that, which are currently discussed at http://www.coreboot.org/pipermail/coreboot/2013-December/076822.html.
However, the likely result is that you'll be forced to use the blobs repository to get usable builds, since some of these binaries really are mandantory on today's hardware.
I found AMD more cooperative, and their binaries less intrusive in the system than what Intel does (and except for microcode updates they're typically unsigned, so with enough time, they could be reverse engineered - but don't wait for it). But they're still miles away from the ideals promoted by Trisquel etc.