So, I've looked over the patch in detail (finally, sorry for the delay).
I'm not convinced on the merits of the patch. As you've stated, the increased speed does not matter much for AVRs. On the finer frequency resolution I would argue, that
a) you still have only 0xffff distinct frequencies to choose from
b) this was (in my opinion) never a problem in the first place.
Let me elaborate: If I program an AVR part, I choose my SPI frequency fairly arbitrarily and rather conservatively, Let's say 100kHz. Whether I can choose 101.6949kHz (12MHz) or 100.3344kHz (for the 60MHz version) does not matter to me at all (the question is, if this applies to all/the majority of AVRdude users).
In contrast to that feature is the increased code complexity and maintenance (Think a new FTDI device). Essentially, it would be necessary (more or less) to copy the switch-statement from avrftdi_open() (handling the different device types) into set_frequency(). I think that is a bad idea. I could live with having set_frequency() called after the switch and the maximum frequency be passed in as a parameter, determined within said switch-statement. This still leaves the command to switch off the divisior - I'm not sure how to handle this in a "good" way, although one could always hope that FTDI builds new devices backwards-compatible (as they already did).

Other opinions/comments/suggestions/arguments?

Programmer declarations for UM232H and C232H are included in r1248.