Looks pretty good so far.

I wonder if it would be worthwhile for failed responses to include comprehensive information about every object that causes a fail, instead of just returning a response for the first one that causes a fail. That way people wouldn't have to make a bunch of batch requests and keep discovering errors one by one. But I don't know if it makes sense to return lists of status codes and error messages in a response. What might be better is to gather lists of objects that cause each error, and then check if each list is non-empty, if so return a failed response for that type of error and include all of the items in the list in the error message. So messages would be like User does not have permission to publish review request(s): 1, 2, 3..

Overall design looks good. Just to help solidify it, it'd be nice to document the format of each possible request payload in the class's docstring.
Some of my comments are things that I know are in flight (and even mentioned in the description), but I'm leaving my thoughts anyway.
The most critical two things in my mind are:

This needs to be more query-efficient. There are places we're going to be repeatedly querying the database, which can lead to poor performance. Every unit test should use assertQueries().
There are some potential security issues in the way that review requests and reviews are being fetched. We should make sure to use accessible checks for possible review requests or reviews, so we centralize that logic and avoid exposing information about review requests or reviews that should be hidden.

Regarding the validation stuff mentioned in the review request description...
I like the idea of being able to validate all the publishes before we publish, and would prefer that if it was easy to do. But I don't think it is. There are a couple of problems:

We could still get errors from writing the review request (such as conflicts) or from the review_request_published signal.
We'd be changing the nature of validation (an extension signal handler on review_request_publishing responding to review request #2 might be sensitive to the published state of review request #1, or that of state expected to be handled in a review_request_published).

(The second point presents a larger issue of, do we need to think about the order in which review requests are published? E.g., following depends_on. That's probably not something to solve right now, but worth considering.)
I think ultimately, we'd be better off doing the full publish operation one-by-one. It's less work, it's probably safer, and it keeps in line with standard behavior.
I do think we should bail at the first review request that fails, though. That's less likely to leave the rest of the review requests in a bad state.
We can provide a list of all review request IDs that published and all that have not, in the order of publish, allowing the caller to continue where it left off if necessary. (Especially useful if we do later make this public API in some form.)

Missing , optional

Mising , optional

Missing , optional

While here, can you move this above Args (and make it Version Changed)?

This should also go up above and use Version Changed.
We've mostly been doing it in order from newest to oldest.

Since this is a private utility endpoint, let's call this _batch/.

Needs a Version Added.

Args are indented too far.

We need to use the accessible queries, or this will end up letting people perform operations on review requests they don't have access to.
Even if we perform access checks later, we don't want to risk the API being used to even infer anything about inaccessible IDs.

In the common case, we'll have the right number of IDs. So instead of a separate COUNT() query, let's jsut fetch the found_ids and then compare counts. This will save a query per batch operation in most cases.

We can simplify this if we just define the proper ID field in the conditional and perform the lookup outside of it.

Let's sort this result, so errors are consistent.

Can we move this entirely into its own function, like the other batch operations?

This also needs to be an accessible check.

Same note above about saving a COUNT() query.

Given the complexity of the arguments (and usage of flags), it'd be nice to force keyword arguments.
Same for others.

For consistency with other errors elsewhere, these should all end with a period.

Since we need to pull drafts, our initial query should do a prefetch or a select_related.

We should catch errors here. Extensions can block publishes.

We should catch errors here.

This is a lot of work, nice job!

I don't see any tests for when there's more than one review or review request and one of them fails to publish/close (leading to a mixed stat in the response).

Could mention this PublishError in the docstring.

Should we check that the error messages in the responses match what we expect them to be?

Same here and for other invalid requests. I think it would be a good idea to check the error message of the response so that we know exactly why the request is failing, and that this matches what we expect.

Seems like there should be a "with" here: "publish op with archive after publish".

Should we add typing here and for any other helper methods in test files?

No period needed here.

No period needed here.

This could be a good thing to add to Djblets' TestCase class, would be useful for other API tests.

A lot of this is typing or doc stuff.
Some of it is optimization questions.
Overall though, it looks great!

For functions that take lots of arguments, I'd like to get in the habit of making the arguments keyword-only (short of any that make sense as positional). This helps avoid complications down the road if we're trying to add or, especially, deprecate arguments.
Can we add a * as the first argument here?

This argument isn't documented.

This should have a Version Added.

The description and argument name don't seem to match? Can we clarify the name?

The type for user wouldn't allow this, so I think the type should probably be Optional[User]?
Also, can you run the type checker through this file again? There's some things in here I'd expect it to notice.

I'd expect updating this to fail type checking. Can we add types for this and anything else that doesn't infer from a call?

If not properly prepared for this function, the following will result in database queries:

review.comments
review.user
reply.comments
reply.user
reply.base_reply_to

That can get expensive fast.
There's a lot going into this. Can we verify that we're not re-querying anything in this code here? If we are, we should fix that up before the call.
Ideally this call would be able to assert that it won't result in any new calls, but that means digging into model caches.. :/

We should add a Dict[str, Any] type here.

T before U.

Can you add -> str:?

Can you update this to use the style used elsewhere where each arg gets its own line?

Trying to keep newer versions first, since those are the ones more relevant when reading through docs.

Rather than Union[..., None], let's do Optional[Union[...]]. While equivalent, it conveys the intent a bit better, and is more consistent.

The ) should be on the next line, with a return type. This parameter should have a trailing comma.

The descriptions need to be indented 1 more space.

While these are being changed, can we update them to use the full class path?

These should be swapped.

reviewboard.testing should be after reviewboard.site.

We could do a .only('visibility') here and reduce what the test has to fetch.

Can we add doc comments for each of these? Especially given that last comment.

Left-over debugging.

This is undocumented.

Given exc_info=True, this can be logger.exception().
Same with others.

This could probably fit fine with user= beginning on the review.publish line.

Blank line between these.

Params can probably begin on the send_email( line.

Might be worth adding a bulk-updating function for visibility. (Doesn't have to be this change.)

This is undocumented.

As above, this can be logger.exception

This is undocumented.

As above, it'd be nice to support bulk visibility updating.

Can you add a Version Added at the end of this?

Should add a Raises for the Http404.

Can you sort these alphabetically?

It'd be nice to do one query with the combined list, and then sort them into reviews vs. replies in-code. One less database query.

Ship It!