This looks great!
Maybe advertise in the javadocs the runtime cost of the collector? (The linear remove method).
In TestPriorityQueue, instead of int numDocsInPQ = (int) (1 + (random.nextFloat() * 100)); you could use TestUtil.nextInt(random(), 1, 100).
Why couldn't you just pass your custom queue instead of null to super() in DiversifiedTopDocsCollector ctor? Scary to have to pass null to super ... something is wrong.
Can you fix diversifying vs diversified naming (pick one)?
Maybe add a random test, in addition to the fixed scores/MAX_HITS_PER_KEY? The random test could do the "slow and stupid but probably correct" diversified collection to get truth, and assert it equals the result using the new collector.
The javadocs are nice and clear (diversify by "band"), but then the abstract method returns NumericDocValues, which is confusing: how does "beatles" become a number? Why not e.g. SortedDVs? Maybe, the test case can show how the nice Beatles example would actually work?
I saw a test about paging; how does/should paging work with such a collector?
I think the changes to PQ are OK. Scary to add a linear-cost method, but it advertises this. If this is too-scary to anyone we could always fully fork to a private (for this collector) impl.