This is by design. The explanation lies in the definition and behaviour of a sorting and paging algorithm.
Let's say that I define the terms pagenumber and pagesize for the sake of this explanation. Let's also assume that there's a hypothetical list of 100,000 things and I want to both page through them and sort them in some way... So the paging is done on a sorted set.
In the case of review queues, we sort history by review date descending and then page it by (I believe) 50 at a time.
The general formula for paging (depending on if you like to start your index at 0 or 1) is:
first record of page = (pagenumber - 1) * pagesize + 1
last record of page = (pagenumber - 1) * pagesize + pagesize
On the first page of historical reviews, pagenumber = 1 and pagesize = 50. When we run this through the formula we're getting records 1 through 50. This means that in English we want to find the top 50 reviews sorted by review date descending. A highly optimized sorting algorithm will begin to search all 100,000 records in a logarithmic fashion and once it finds the top 50, it will immediately stop sorting. It only had to find and sort 50 records in order to display page 1. So cost = 50. This is fast.
Now we want page 2. pagenumber = 2 and pagesize = 50. When we run this through the formula we're getting records 51 through 100. This means that in English we want to find the top 51st through 100th reviews sorted by review date descending. A highly optimized sorting algorithm will begin to search all 100,000 records in a logarithmic fashion and once it finds the top 100, it will immediately stop sorting. It had to find and sort the first 50 to know where 51 through 100 lie in the list of paged results that are sorted. So the cost = 100 to display page 2. This is twice as much work (on average) as page 1.
Page 3... cost = 150, 3x as expensive (on average) as page 1.
Now, since we had 100,000 rows and a page size of 50, the last page is pagenumber = 2000. To display this page, we have to sort EVERYTHING before the last 50 results in order to display the last 50 results in the proper order. In other words, the entire result set must be sorted to display the last page. Here, cost = 100000 which is very expensive.
This is why the last pages of the historical review are slow.
There are optimizations that can be done with such sorting algorithms. One such optimization is to pre-sort and store the list in a sorted fashion, so that all records are direct lookups. This takes up a lot of memory. Another optimization which lets the data remain dynamically sorted is to guarantee a cost no greater than 1/2 the result set by sorting by the reverse for the last half of the records... In other words, the first 50 records are cheap for a review date descending query, so the first 50 records of review date ascending are also cheap, and these would coincide with the last 50 records of the review date descending sort. We could do this and limit the cost in our example to cost = 50000 (the most expensive sorts being the middle of the set), but it is easier said than done.
I hope that this explains why you're experiencing slow historical pagination.
