Question: Where should I document the options that I added (descriptorText, minDate, maxDate)? I'll remove the comments that are next to them afterwards.

I'll cover some of the stuff in the HTML and the CSS in this comment.
Our modern CSS component conventions basically define two ways of naming a CSS class for something within a component:

component__child, of which there should really only ever be one level of nesting
-modifier, which is tacked onto a component/child CSS name to modify something about it.

A big part of the approach with this is to think hard about the structure of the component, giving everything a purpose. So rather than "these things go in <p> tags", we want to think "these things go in these named child objects."
So let's go through and see how we can take advantage of that here.
The HTML in this change is introducing:

rb-c-config-api-tokens__info-is-invalid
rb-c-config-api-tokens__info__expires

This is close, but not quite to spec.
Looking at this, it seems this specific section has essentially four states:

Token is expired ("Expired ...")
Token is valid and will expire ("Expires ...")
Token is valid and will not expire ("Never expires")
Token is invalid ("Invalidated ...")

We could go a couple ways here. We could combine these under one concept ("lifecycle" or "state" or something?) or break them into multiple types of children.
Let's go with the former. We'll call this rb-c-config-api-tokens__token-state, and control the state through modifiers:

-is-expired
-is-invalid

We'd only ever use one at once. Think of it like enum values. If neither are set, it's in a default situation.
(We should also have rb-c-config-api-tokens__usage, to cover the "Last used"/"Never used". Even if we don't style it differently. We're defining the component structure.)
Now I think ideally, we'd actually give each token item its own full CSS component, moving things like the state modifiers (-is-expired, ...) to the main component class. That's a bigger change, though, and I'd rather think about that separately.

Since it's just 0, no need for em.

This line is too long.

For JavaScript, multi-line comments should look like:

/*
 * ...
 * ...
 */

Date objects in JavaScript are the absolute worst, and doing operations on them scares me. So many things can, and will, go wrong.
I'd recommend we instead use the moment.js library. This library lets us do operations on dates without worrying about the problems that tend to come up, and keeping code very self-explanatory. We already bundle this with Review Board.
We also have to be very careful with timezones. Some notes on that:

new Date() always gives us local time in the browser.
Timestamps we get from the server contain timezone information.
Timestamps we're sending currently do not, but they need to.
If they don't, the server will interpret them based off the timezone in the Profile, which may not match
We want to be sure we always show local time to the user.

Okay, so let's update the code to be more readable, safer, and timezone-aware:
This first block can work like:

// Here, we're operating in local time, and can perform some safe date math.
const tomorrow = moment.local().add(1, 'days');

/*
 * Since we're dealing with a server-side value (as per #2 above), we know
 * we have the timezone, which moment() will handle. We also want to convert
 * to local time.
 */
const expires = moment(this.model.get('expires')).local();

...

// Now we can format that how we wish.
{
    ...
    minDate: tomorrow.format('YYYY-MM-DD'),
    rawValue: expires.format('YYYY-MM-DD'),
}

// To build a timezone-aware midnight ISO 8601 timestamp off a local timestamp to send to the server:
moment.local(value).startOf('day').format()

// *If* we had wanted to explicitly convert to UTC, but with midnight local time:
moment.local(value).startOf('day').utc().format()

etc.


It's quite a nice library, and if we're careful and explicit, we avoid a lot of timezone conversion issues.

No need fro the parens here.
We should include a default value inside of <time> though.

Two notes:

We should keep this alphabetical.
The last item should have a trailing comma (safe for ES6 files).

As a ES6 file, you can do:

$(window).on(`resize.${this.cid}`, ...)


Also, this can be one line.

As this will be (eventually) ReStructuredText, code literals need double backticks.

5.0.

This won't ultimately parse right. Instead, let's use our standard doc syntax we'd use for any attribute.

/**
 * Summary here.
 *
 * Optional description.
 *
 * Type:
 *     ...
 */

I suspect this can fit in one line.

Let's be explicit about local time vs. UTC in these.

<input> tags don't have an end tag, so this should be <input type="date"/>.
How important is it that we have the <span>?

.attr takes a dictionary of keys/values, which is good for multiple attributes.

When there's no need to continue chaining, you can keep this as one line.

If this never changes, it should be const.

These cam use <URL> if decorating with @webapi_test_template.

Let's add/update tests to do some explicit checking around timezones and conversion.

I think it makes more sense and follows our CSS docs standards more if I document these modifiers above the &__token-state component. But then where should I document the -has-last-used modifier for rb-c-config-api-tokens__usage?

Should be </p>

I don't see usage in here.
Even if we don't style it, we should have a documented block and an empty rule for it, so the structure is clearly-defined.

The * should all be aligned.

We should pick one, and use styling to ensure consistent presentation (being explicit about any margins/padding that would otherwise be up to the browser for something like a <p>).
Especially since <span> is inline and <p> is block-level. That can make it hard to maintain. Can we stick with <p> for all?

</...> for end tags, <.../> for self-closing tags (like <input> or <img>).

These can be one rule:

&.-is-expired,
&.-is-invalid {
    color: red;
}

The caller may pass null (as per the event handler further down). We should document what happens if passed.

saveExpires is indented 1 space too far.

Maybe it'd be better to just store _$tokenState, and then we can determine things as-needed based on the modifiers?

No need for a blank line here. These are related statements.

I'm not sure if async is needed here, since I don't think we're dealing with any functions that also need to operate async. I might be wrong. If so, can we document this?

Let's put parens around this so order of operations is very clear.

Let's hard-code the dates we want to set and compare, to ensure there's no variability based on time wonkiness. "now" dates in unit tests can become difficult to debug when things go wrong.

Same comments about "now" timestamps. Let's hard-code known ISO 8601 timestamps and check results explicitly.

expiresTimeHTML needs to be passed in when instantiating the template. I don't see that happening in this change. That would need to be done by returning it in getRenderContext().
By default, a template for a ListItemView gets possible <%= ... %> variables from the model attributes or from getRenderContext() results.
It would only make sense to do this if you are trying to also set datetime= here, and if we're taking this same approach for all other <time> elements in this template.
Otherwise, it doesn't really make sense to feed in <%= expiresTimeHTML %> at all, just for an empty-by-default <time>. If the goal is to just save a few characters but to populate this tag dynamically after, just hard-code <time></time> here and let that code take care of it.

datetime would be more technically correct.

check_post_result does a good job of making sure the response and the resulting object match expectations, but we still need to explicitly compare the resulting timestamp in these tests and make sure they contain the value we expect them to.

One last thing :)
We want to keep the model as the owner of this value. Models keep state/state-related logic, and views represent values. By duplicated storage of state, we risk things getting out of sync.
The ideal setup is to have the UI always update based on the model. To do this, a lot of views will listen to a change:<attr> for a given attr name that the UI depends on. Some UIs will then selectively update appropriate parts of the DOM, and some will just call render() again.
This view doesn't do that, which is fine (that very well may change down the road), but the ability to do that depends on avoiding duplication of state from the model. If we copy it here, and use this copy, we get out of sync.
So let's remove this here, and instead only pull out at the times we need it.

dedent is no longer needed. You can just use backticks.
Right before this statement is where we should pull out expires. Just to keep as much logic out of the string as possible, referencing only variables.

Rather than depend back on expires, we want to check the exact generated timestamp string we want to see.
The goal is to be very explicit about what we expect to come back, so we can protect ourselves from any issues introduced by logic changes down the road to either the executed code or the test itself. It also gives us a reference if debugging things down the road, so we know precisely what format of string we think we're working with.

We want to avoid a multi-line string here (this will capture all whitespace inside the of the backticks), so let's put the backtick as close to the tags as possible. It's okay to start this on the second line. So:

return {
    expiresTimeHTML:
        `<time class="timesince" datetime="${expires}"></time>`,
};

We just need to make sure the user's profile's timezone is actually taken into account. So what I suggest is something like:

profile = self.user.get_profile()
profile.timezone = 'US/Eastern'
profile.save(update_fields=('timezone',))

# ....

# Make sure resulting timezone is offset from Eastern.


Same idea for the PUT.

Ship It!