Well, the idea of "top N documents" is, imo, distinct from how it is implemented, (e.g. with lucene's internal PQ impl).
I think, at some level we disagree on what TopDocsCollector is "for", you say it's for a PQ implementation; whereas, I think it's for the public interface, namely:
getTopDocs(..) and getTotalHits(). The that fact that the implementation uses org.apache.lucene.util.PriorityQueue is not necessarily a positive thing for my purposes.
Alternate impls certainly could subclass Collector directly, but much of the time when getting documents, getting a TopDocs is preferred, and there is value in expressing that capability abstractly. And there is value in expressing accomplishing that w/o being tied it to a single possible implementation. Overall, the PQ based impl is effective, but that doesn't mean that it's always the most effective impl capable of yielding TopDocCollector functionality, and by that i mean the public interface.
I have uses of this code that require referring abstractly to Collectors that produce TopDocs, doing that without any common interface or abstract class (whole separate issue with the fact that Collector is not in iface & ditto TDC) requires wrapping a TopDocsCollector in a proxy, which is just kind of silly to me.
Also, i'm entirely missing the downside?