• Is it easier to allow full pagination of these results anyway?

In short, no.

• The similar-users API does not paginate results
• We could add pagination in the extension, but we would not be requesting any fewer results from similar-users, because of the above
• We couldn't make use of the MediaWiki pager infrastructure, because it assumes that it is paginating database rows via SQL queries. (E.g. pagers build a query via the abstract method getQueryInfo, defined on IndexPager, which is overridden to define tables, fields, join conditions, etc.)
• The tool does not aim to show a large number of results, so there would be no visual/performance need for pagination

• Is it better not to use the pager functionality, but only the <table>-building functionality?

We shouldn't subclass TablePager:

• The MediaWiki pager classes combine building paginating database queries with building the HTML for outputting the results
• We want to output similar HTML to the TablePager, but without the pagination
• It is not easy to use only the HTML-building infrastructure, because TablePager's HTML-building methods assume we are working with database rows. (E.g. TablePager::formatRow builds the <tr> using a database row object as input, which is expected to have a $field property, etc.)

We can still ensure visual consistency with special pages that use tables by:

• Using the mw-datatable class on the <table> element
• Using the sortable class on <table> and loading the jquery.tablesorter module so that rows can be sorted, as depicted in:

Moving this to Done, now that it has been discussed in the engineering meeting, and a follow-up task filed: T307023