Definitely use Barracuda. I was already using a number of DNSBLs, but things were still falling through the cracks; when I added Barracuda it had a noticeable effect.
I actually don't use zen, preferring to query sbl, pbl, and the components of xbl (cbl and njabl) separately. The reason for this is that, last I checked, the xbl wasn't updated in realtime. So a listing could appear in cbl or njabl before it showed up in xbl. Cbl in particular is based on spamtrap hits, so timely information can make a difference in stopping an incipient spam run.
I also use spamcop and quite a few other blacklists, including several based on country of origin. (This is acceptable for my organization; it probably wouldn't be in other environments.)
This is a good resource for keeping track of available blacklists:
Blacklists Compared
The downside of using a bunch of DNSBLs of course is extra time and load due to the lookups, but our current (non-Zimbra) server doesn't have a problem.
When/if we switch to Zimbra, I expect to pare the DNSBLs and rely more on server and client-based content filtering, as that gives users more control and will hopefully reduce complaints about false positives.
I also make extensive use of custom blacklists. On my current system I have a content-based plugin running which sends me daily reports of which IP addresses have been the sources of the most spammy-looking mail. I use this information in conjunction with Senderbase lookups and WHOIS records to decide whom to block. (WHOIS records that have the owner information hidden by a privacy service like Moniker, etc., are highly suspect in my eyes.)
(EDIT: I wonder if Zimbra's content-based tools can provide a similar summary?)
Should the tools provided by Zimbra (and the Wiki) need supplementing, another idea is to implement ASSP. By moving some antispam functions onto a separate box, this would also take some load off of Zimbra.