One of the major reasons why I switched this particular relay over to milter-greylist was peering. The relay I was rebuilding is actually a secondary relay, with the primary running relaydelay. Once I'd configured milter-greylist on the secondary relay, I did the same on the primary, and set up the peering between them, so that they share the same databases. This feature is particularly handy.
Overall, milter-greylist works quite well and uses a fairly straightforward configuration syntax. It would be terribly handy if the config supported includes, since that would make scripted blacklist/whitelist additions much simpler. One of the best features of relaydelay was that the whitelist and blacklists were actually just rows in the database. Thus, they could be added/deleted/updated on the fly with instant results, and no need to restart the daemon process. I've used this to write simple perl and PHP scripts that automatically modify rows in the database depending on outside influences, such as the presence of a particular email in an IMAP subfolder. Thus, if I drag a spam into a specific folder, within a few minutes, the originating relay for that email has been blacklisted by that code. Very handy.
Milter-greylist uses a fixed configuration file for whitelist/blacklist features, and while it's very easy to work with, it's far more difficult to wrap into a management layer. It might also be useful for milter-greylist to accept configuration requests during runtime. That way, blacklist/whitelist/acl entries can be added/deleted/modified on the fly, and the various tables and acl entries could be dumped to file like the database. Something akin to pfctl would be dandy. Oh, and the permissions on the database dumpfile should be a configurable parameter.
The lack of any Web UI element makes it difficult to delegate day-to-day monitoring to those who don't have administrative access to the relays, but I did throw together a very simple milter-greylist monitoring/searching UI written in PHP, which I'll release at some point in the near future when I get a few bugs ironed out and make it a little more robust.
There are other open source greylisting tools out there for just about every MTA, and even some commercial variants exist now. In many cases greylisting works very well and can significantly reduce spam volumes, but it's not for everyone, especially if you can't handle the chance that an important email may be delayed for a few minutes at best. Otherwise, it's definitely worth the effort.