The main reason I've disabled post revisions on a couple blogs is this feature seems to conflict with some common uses of Custom Fields, at least when writing your custom fields via some popular plugins. In the forums here, there are numerous threads of people whose custom fields implementations were borked by WP 2.6 and the problem was fixed by disabling Post Revisions. Yes, of course, some of these problems have to do with Plugins that we use to handle our custom fields, and yes I understand the plugin should be fixed, but in the meantime people can't really live with a broken website while we wait for plugins to become compatible with Post Revisions. While it may be a great feature, it's a feature that "I never knew I wanted" so I'll certainly live without post revisions rather than live without the essential custom fields features, which my site is built on.
I don't feel like I understand enough details to post about this as a bug on Trac myself (have never done that before, myself, as of yet, it seems techy but maybe I should try it). Maybe it's not even a WP bug, but rather a plugin compatibility issue. We can blame the plugin, but I need the plugins and I don't exactly NEED Post Revisions.
Additionally -- on my other blog, where I left Post Revisions enabled and checked it out, it was attributing the Edits to the wrong author names anyway. I (the Admin) would edit posts, and the Revisions box in Write Post would still say "Authorname edited" instead of "Admin edited". When I actually know that Authorname hasn't been on my blog in months. That issue also made it come across as an unfinished feature on first look (2.6).