In that case, the kind of outlier you'd run into is a post that is updated daily or frequently to track current events. You could possibly end up with hundreds of revisions and it would be harder to access them individually if they're all in the same big archive. You could limit the size of each archive/digest to mitigate that issue.
I don't think that having lots of rows in your revisions table is an issue. After all, there will be even more rows in the posts table. That's why I wouldn't look for ways to free up rows in that table. The only potential issue would be with big posts that get edited a lot. I don't think that happens often enough to be a priority, but if I had to deal with it I would archive the content of old revisions as I mentioned earlier. I would leave all of the metadata intact and I would only archive their text. I'm not sure what the DB schema would look like; If the revisions are numbered sequentially, the archive table could have 4 columns for the post'id, first revision number, last revision number and the content. If each revision as its own unique ID, you'd have the archive table as archive id, post id, content, and a relation table with revision id, archive id.
