Will change {{forloop.counter0}} to 0

This trailing comma will break older browsers, since it's outputted directly to the browser, and is not in a .es6.js file (which would compile suitably for the browsers we need to support).

Django's MultiWidget also takes in a child widget (well, a list of them). It accepts either a class or an instance in the constructor, and if it's a class, it'll instantiate it.
I think that's the right pattern, and the right default. Taking in a class just stores a reference to the class in the list of default values for the function.
Making the default an instance means that:

We instantiate the TextInput and keep this around forever (using memory that may not be needed)
We actually share that default instance across all ListEditWidget instances by default, which could lead to errors with state being clobbered.

Let's make the default a reference to the class, and then in the constructor we can instantiate it if it's a class or store directly if the caller provided an instance.

This could be one statement.

No need for parens around name. In fact, (name) is equivalent to name. If we instead had (name,), then it'd be a tuple with one value (name) in it.
A tuple is often a correct thing to pass in using %-based formatting, but isn't necessary in this particular case.
Caveat: If the value being passed in was iterable (a list or tuple, for example), we would need to wrap it as (value,), or the %-formatting would be looking inside of it for values to stuff into the %s and such.

I suspect we won't want to use attrs itself here. Those are the attributes for the ListEditWidget, which will probably differ.
A base set of attrs are generally provided upon widget instantiation (or overridden in the widget itself), and then built upon when it's time to render. So starting out, we'd probably want:

widget_attrs = value_widget.attrs


Which we could pass in to render().
If we wanted to add our own attributes to each value (say, giving them each a unique ID in the DOM — something worth considering in the future — consider the following an example only), we'd do something like:

common_widget_attrs = value_widget.attrs

for i, val in enumerate(value_list):
    widget_attrs = {}

    if 'id' in attrs:
        widget_attrs['id'] = '%s_%s' % (self.id_for_label(attrs['id']), i)

    render(
        ...,
        attrs=value_widget.build_attrs(common_widget_attrs, widget_attrs))


So, taking those base attributes, and then modifying them on each loop so it's suitable for that row.
For reference:

enumerate wraps an iterable, yielding an index and the value for each iteration.
id_for_label returns a suitable ID for the widget.
build_attrs takes in common attributes and specific attributes and returns a new dictionary combining the two.

We reference self.value_widget many times. Each time we do that, we have to go through the attribute accessor paths in the class. Not particularly slow, but not worth doing. Let's pull out value_widget into a local variable before the loop above, so accesses are fast.

Missing a trailing comma.

Technically, this makes this a breaking change, which requires a Djblets major version bump (we follow semantic versioning in Djblets, at least nowadays).
This is probably fine, since we're targeting Djblets 3.0 for this work, but we need to document this with the following before the Args section:

Version Changed:
    3.0:
    * Removed the `inputAttrs` option.
    * Added the `renderedDefaultRow` option.


(Also, renderedDefaultRow will need to be documented.)

So here's a big thing I missed in my prior review (and this is all from the original design, which makes modernizing this tricky).
This code is still assuming that we're dealing strictly with individual strings (and that we can just split them). That isn't safe, as the widget may be returning an integer, a list, a dictionary, or even string-encoded content that may get split wrong.
However, we don't want to break existing consumers.
The problem comes down to the original design. This assumed it was only ever going to work with strings, and that the data being fed in was a string that had a valid separator.
It should have been designed to work in conjunction with a matching field that prepared the value before it got to render(), turning whatever the content would be into a list of values that pertained to the widgets.
Basically, it should be the job of the field to prepare data and the job of a widget to render it. The widget shouldn't have to be parsing anything.
So I think we can work our way toward this design by doing the following:

In render(), check if value is a list. If so, we're good. This is modern. If not, convert it to a list through this existing logic we have here. (Update the code to reuse value, instead of value_list, to make it clear that this is what we expect of it.)
Add a comment saying that we plan to deprecate this behavior. In a future release, we'll enable deprecation warnings for this code path.
Introduce a djblets.forms.fields.ListEditField. This will be the new field intended to work with ListEditWidget. Its job will be to take in a string and convert it to values, and to associate ListEditWidget as the default widget. Subclasses (such as your field for the Pygments work) can do that conversion however is needed. By default, it should split in the same way that the widget otherwise would.

This effectively gives us a migration path to that ideal world in which the widget just renders, and the field handles the data processing. It would then be really easy to subclass these and get the data and widget setup in the right form.
That may sound like a lot, but the field work isn't going to be too bad. Not documented as well as it should be, but I can guide you through any of it.

It's possible that when you are creating ListEditView here, it is not defined, That's why the error Cannot read properties of undefined (reading 'ListEditView') happens? I would try to see if I can do something like console.log(Djblets.Forms) just to see if the class is properly imported/accessible within this HTML. You might need to add extra code to specify where to get the ListEditView from

Are you calling/importing the Form correctly? Adding the correct classes (ex. multipart/form) when rendering it in the HTML? Does new items in the listeditview require a different form of parsing than just parsing the text?
I would also console.log() it out to see if the result is what you're expecting, and check the types of the results too.

I know this is still marked WIP, but it's looking really solid so I did a pretty thorough review.

Typo in summary: dbjlets -> djblets

Please wrap the description/testing done to 70 columns.

You're actually storing this as _sep in the __init__ method. We don't need to have any documentation for purely internal/private attributes, unless they're particularly confusing or complicated.

This can be dedented 4 spaces.

Dedent 4 spaces.

This should just be indented 4 spaces, not 7. Even better would be to reformat the docstring so the first line fits on one line and move any details into a second paragraph.

Because this init method doesn't do anything but call the superclass, we can just get rid of it.

Dedent 4 spaces.

Dedent 4 spaces.

This should have a "Raises" section with django.forms.ValidationError

This new line can go away (plus you added some trailing whitespace).

This new line can go away (plus you added some trailing whitespace).

Please add a module docstring for this.

Please add a module docstring for this.

We generally avoid the python ternary syntax because it's not particularly readable. Let's just make this an if/else.

Add a blank line between these two.
For properties, we can also skip "Returns" and just put in:

Type:
    django.forms.widgets.Media


because callers can use it as if it were just a plain attribute and not a method.

We do sometimes say "list or unicode" to clarify here.

Trailing whitespace on this line.

Trailing whitespace on this line.

Trailing whitespace on this line.

Trailing whitespace on this line.

Trailing whitespace on this line.

Trailing whitespace on this line.

We don't use var in .es6 files. That said, if you change the .each() to use a fat-arrow function, you can just use this directly instead of aliasing it to self.

Please keep the import list alphabetized

Add a blank line between these two (in python classes, there's one blank line between each thing, and the docstring counts as a thing).

These are each indented one space too many.

Each of these lines needs to be indented one more space.

This new line can be removed.

Add a blank line between these two.

Add a blank line between these two.

f before w

Test docstrings shouldn't have a period at the end, because the test runner will print an ellipsis.

Type definitions don't need an explanation, just the type name. The explanation of the property is in the docstring above this.

Add a blank line between these two.

This line can go away.

Instead of passing in len to filter, we should use None. This will do a falsy check instead of actually checking the length of the string, which is ever so slightly faster.

Type here can be jQuery

It looks like this is taking in a jQuery, so we should list that here and call the argument name $entry

Let's define a variable for $(el) so we don't have to construct the jQuery object twice.

Should this be removed?

Can we change the summary to be "Modify" instead of "Modifying"?

It would be nice to write the testing done as a set of bullet points. Right now it's kind of hard to read.

We no longer need this on djblets release-3.x or master.

We no longer need this on djblets release-3.x or master.

We need to add some blank lines between all of these.