I didn't do a full review, since I'm pretty exhausted right now, but here's a few things that I noticed from a cursory glance.

""" on the next line.

We should be using format_html. Would also be nice to use dictionary args for formatting.

Should use format_html here too.

Should use single quotes.

Swap these.

Blank line after this.

Blank line between these.

How about post_field_html instead of extra_html? Would be nice to be explicit there, in case we decide to allow for custom HTML before the <span>.

Ping?

If we don't mind a little extra '/' stripping, this can be:
diffed_files = [
    fd.source_file.lstrip('/')
    for fd in diffset.files.all()
]

Don't we have some normalization somewhere now for this?

Alignment looks weird.

Let's swap these conditions. rr_id != self.pk is a faster check.

This can be:
user, user_timestamp, related_review_request = all_reviews[rev]

I don't know if it's faster to use six.iteritems here, but since this will be the equivalent of iteritems on Python 3.x, we might as well use it for 2.x for consistency.

This is formatted awkwardly. How about:
sorted_users = [
    user
    for user, weight in ...
]

Can we pull out .suggest-user once, instead of re-querying every time?

With the exception of selector above, all of these are in alphabetical order. Can we move these (and selector) to be consistent in that way?

Should just use a pre-fetched element.

This looks to be doing too much. If we kept this logic, then this could just be:
this._$suggestedPeople
    .empty()
    .append($allPeople);

However, I'm not really sure why we need to do all this work. I wasn't sure why we were, but I suspect it's because we insert those ',' characters. If so, we're just doing way too much work here.
What I'd suggest is not doing any of this, and instead just list the visible users as standard elements. Then, in CSS, we can do something like:

.suggest-user:after {
    content: ", "
}

.suggest-user:last-child:after {
    content: ""
}

Tool: Pyflakes
Processed Files:
    reviewboard/reviews/builtin_fields.py
    reviewboard/reviews/models/base_review_request_details.py
    reviewboard/reviews/fields.py

Ignored Files:
    reviewboard/templates/reviews/review_request_box.html
    reviewboard/static/rb/css/pages/reviews.less
    reviewboard/static/rb/js/views/reviewRequestEditorView.js



Tool: PEP8 Style Checker
Processed Files:
    reviewboard/reviews/builtin_fields.py
    reviewboard/reviews/models/base_review_request_details.py
    reviewboard/reviews/fields.py

Ignored Files:
    reviewboard/templates/reviews/review_request_box.html
    reviewboard/static/rb/css/pages/reviews.less
    reviewboard/static/rb/js/views/reviewRequestEditorView.js

Col: 80
 E251 unexpected spaces around keyword / parameter equals

Col: 26
 E127 continuation line over-indented for visual indent

Col: 80
 E501 line too long (80 > 79 characters)

 list comprehension redefines 'user' from line 195

 list comprehension redefines 'weight' from line 206

We fetch all the diffsets in review_detail. It'd be nice to make use of those to grab the latest, if available, to reduce a query.
I'm very concerned about the impact this feature will have to load times, so any query reduction we can do is very important.

This terrifies me still. It's a large join. We should do some testing against large MySQL databases before this goes in. I'd like to see whether it's faster to do a large join, or to split it into a couple different queries.
One thought on optimization:
We're going to fetch a lot of user data, and a lot of it may be the same data. Instead of grabbing 'user', let's just grab the ID, and then after we dedup later, we can fetch the data we need from those user IDs. Same for the reviews__user.