I typically do what is natural for the given situation.
When using bind, depending on the situation, I will typically run 2 masters and several slaves.
Changes are made one master; those changes are validated then rsynced to another master. That master uses zoen transfers to send the zones to the DNS servers clients see. The other two aren't advertised. (the first master isn't strictly necessary, but it is nice to have a scratch monkey) I also like having 2 copies of the server configs and 2 copies of the zone files in a proper format (instead of the copy you get on a slave server). Care must be taken in making sure the server reloads the zones only after the rsync finishes.
When you're using AD for DNS, you don't need to worry about exchanging zones between servers -- the AD protocols magically take care of synchronizing everything.
PowerDNS expects that you will use zone transfers or you use some database replication mechanism to keep things in sync.
TinyDNS can use zone transfers but if you're transferring files within the same organization it makes sense to use something like rsync because the tinydns server makes reloading zones safe and easy.
Lastly, and most importantly -- use zone transfers if you're exchanging DNS zones with organizations outside of your direct control. For instance, it is common place to have your ISP host an authoritative server for customers. That server will be a slave server and get the zones via zone transfers, regardless of what type of DNS server the customer is running. Similarly, if I outsource my DNS to a provider like UltraDNS, I'll insist on being able to do zone transfers of my zones from their servers, so I can leave them at any time by updating the registrars to use my servers instead of theirs as the authoritative servers for my domains.