You're delving into a lot of complex stuff, which is great! And you've done a great job with the change. As I've been reviewing it, though, I've been mulling over what it is we may really want to do with this sort of view, and have some thoughts.
Take this as a proposal. I'm sure there will be differing thoughts on it.
There's two things that stood out:

The new counter is maybe not necessary, and if we can avoid it, that'd be awesome. Database changes are expensive and invasive. One seemingly simple database change can turn into hours or days of upgrade time for some customers. This one's easier to handle, but if it were on, say, ReviewRequest, we'd definitely be looking at weekend downtime. So we try not to add them unless necessary. And we only need this if we use the current design. Which is where my second thought comes in.
The name "My Reviews" is not quite right for what this is. First, these are review requests, not reviews. Second, they're not all "mine." I know the original project name is "My Reviews," but we can do better, and be less confusing to users. Along with this, the "All" item underneath it is inconsistently named, as "All" in "Outgoing" means "Even ones that are closed." There's only a single item in here, though, which is maybe not necessary.

I think we can address both of these by making two changes:

Renaming "My Reviews" to "Overview".
Getting rid of the "All" item, and instead folding that into "Overview".

I don't think we even need a counter for this. It can just be "Overview." Let the finger-grained sections below supply the counters. They're more useful that way, and it frees us up to do things with this section later (I have some pie-in-the-sky ideas for showing more useful information than just a list of review requests down the road, which would make a counter less relevant anyway -- backburner idea for something I call "Radar," but that's a longer discussion.)
This would look something like:

This would massively simplify the change, though you would need to allow sections to be selectable/made active, so there's some new work there. The counter work could be tossed, reducing the amount of unit tests and query consolidation I was going to have you write (counters are complex), and we'd have something that we could land pretty quickly.
With that in mind, I'm going to drop a bunch of comments I had for the counters. If it turns out that you're going to end up having to add them anyway, I'll have a bunch of comments in a separate review.

Some general things to note about evolutions, in case you need to do them in the future (or now, if we have to keep this counter):

The name of the evolution should describe the model schema changes, not the reason you're making the model changes. When adding fields, this is gneerally going to include the model name and field name. For instance, localsiteprofile_total_request_count.
This needs to use underscores, not hyphens.
Last item in a list should always have a trailing comma, so this line doesn't have to be modified next time we add an entry.

This is wrapped way too early. You have more room on the line for content.

This will need to follow the modern documentation format, with a Yield section. Someone at the sprint can point you to the docs for this.

We'd update this to "overview".

Two blank lines between top-level classes/functions/groups of variables.

These should be in alphabetical order.

For now, let's not set this as the default view. Users can find these sorts of changes to be very disruptive, which means us fielding a lot of support requests :) For now, let's keep the existing default view, and make the new Overview an optional thing users can go to. They can always bookmark it if they want.

This needs to use our modern docstring format.

This will need a docstring. (Many of the others are missing this, but they predate the current standards. Don't worry about those, but provide one here.)
I'd also like this to be called to_or_from_user.

Usually commit messages are descriptive (e.g. what the patch does) instead of declarative (what I -- or you -- did to write the patch).
e.g., for your second paragraph:

The dashboard now contains a new section that contains all review
requests that the user is either a submitter of or a reviewer (either
directly or indirectly).

Can you update your summary with the new section name?

This will require at least one unit test to ensure the query returns the correct review requests.

The right caret will have to align with the "Overview" text. You'll also want to bump its font size up (try 200%?)
You might want to try the following:

Wrap the Overview and caret in a <span>/<div> and style it with line-height: normal
Wrap and style it with vertical-align: middle.

If neither of these work, we can help you figure out the appropriate styles.

Just one more minor thing!

We avoid inline styles as much as possible. Instead, can you put a class on this (maybe overview-section-row) and add the styling to a LESS file?
It should probably go in static/rb/css/ui/sidebars.less.

You'll notice these comments are pretty nitty-gritty, which means this is getting very close to a ship it and we're just working on polish!

The other docstrings quote the section name, e.g.

The "Overview" section ...

Since you're updating this, can you update this to our documentation style?
Also, technically, for reStructuredText, this list is mis-formatted (not your fault); instead the * should be in the same column as the V in Valid ....

The summary should be on the first line and should fit on a single line.

This should be in the imperitive mood, as if it were a command (i.e., "Return" instead of "Returns").

This should be formatted as

:py:meth:`ReviewRequest.objects.public <reviewboard.reviews.managers.ReviewRequestManager.public>`


which will format it as a method invocation and link to the correct place in the docs.

This is actually a Q (django.db.models.Q) object.

How about:

A query for all review requests the users is inolved 
in as either a submitter or a reviewer (either directly
assigned or indirectly as a member of a group).

i.e does not end a sentence. It is a joining clause .

The summary should be on the first line and should fit on a single line.

QuerySet

Missing a period.

The actual class name is dict

Missing a period.

Same comment re: wording as above.

Return documentation is formatted as:

Returns:
    django.http.HttpResponse:
    The rendered HTTP response for the datagrid. What datagrid is rendered
    depends on the ``view`` parameter.

this should go above args in the documentation noting that the view GET parameter is used, e.g.
```python

"""Display the dashboard.
This shows review requests organized by a variety of lists, depending on the view GET parameter. Valid values of view are:

outgoing
to-me
...

Args:

   ....
Returns: 

   ...

"""

Looks good to me! Just need another sign-off on it before landing.

Typo here: 'mine'to -> 'mine'

Although we often use six.text_type in the code, docs should use unicode in order to link to the right thing.

Typo: objectts

Ship It!