I think I'll wrap it up here, I got some very useful feedback and had plenty of time to think it over. :) I collected the conclusions in T254074: Implement the reverted edit tag and will start implementing this soon, probably.

It turns out Minerva disables enhanced RC altogether through a hook: https://gerrit.wikimedia.org/g/mediawiki/skins/MinervaNeue/+/0c488fa4f775815e96a64924c6b24ecd128a4b1b/includes/MinervaHooks.php#71

After some messing with CSS I think there's something wrong with Timeless's styles for OOUI icons, from what I see Minerva does them quite differently. I'm not sure how to fix this, though, OOUI's CSS scares me.

In T181321#6157505, @Ostrzyciel wrote:

It may a bad idea though, we will see if we run into some problems because of that :P

In T231246#5488937, @Isarra wrote:

Note that this already works fine with MF, and probably belongs in core...

We had a similar issue with that CSS rule in this template, the icon was disappearing on narrow displays. We tried to find places where this rule is actually helpful for us, but we couldn't find any, so we disabled it completely.

In T252366#6154732, @kostajh wrote:

My first reaction to this is that we shouldn't say that a "revert edit" is a judgment about good or bad, just a reversion of text to a previous version. So I don't think this is something to worry about, personally.

I thought a bit about revert wars and how would this feature work with them. Suppose we have a series of edits, in chronological order:

1. User Alice
2. User Bob
3. User Alice, reverts to version 1
4. User Bob, reverts to version 2
5. User Alice, reverts to version 1
6. User Bob, reverts to version 2

This is not directly related to the task, but I thought some of this may be useful to someone. I'm the maintainer of the AdvancedBacklinks extensions that lets you track links through transclusions and can get you easily in a psychiatric hospital. Anyway, this extension has a special page very similar to Special:WhatLinksHere, just enhanced with a few neat features. I recently rewrote some of this special page to use OOUI and the end result is this:

Thank you @nettrom_WMF, that research paper is indeed very good. It also led me to thinking of cases when a reverted edit is reverted back, that would have to be handled nicely. I will have to think this through carefully, as I can think of many weird cases that would be tricky to solve, i.e. what happens if there is a revert war longer than 15 edits. This also leads me to think implementing this can require something more complicated than just a revision tag.

I am forced to abandon this proposal, as there was nobody willing to mentor this project.

In T247406#6002030, @ssastry wrote:

The current plan is to pursue switching over everything to Parsoid on the Wikimedia cluster in the 15-18 month timeframe -- or at least pursue that timeline and see where we land.

I am not sure if the above proposal is sensible or not in technical terms and some feedback from people that know these modules well would be much appreciated :) I am also looking for people willing to mentor this project.
I contacted @srishakatux before regarding this project and she recommended me to ask a few people regarding that, so I'm tagging them here.
@ssastry @cscott @Anomie @cicalese

In T246127#5916748, @Reedy wrote:

Did you mean REL1_33? I looked and it seems like 8f666cabcdcda75fa9cfe2409444861cccb36877 only came in in REL1_34

@Aklapper: Ah, you're right, I forgot to close it :)

In T232305#5751851, @cscott wrote:

I suspect a more forward-compatible hook would be to hook link resolution, and pass in a reference to the frame there. The legacy parser is being replaced by Parsoid, so hooks based on the legacy parser aren't going to be maintainable long-term. However, Semantic MediaWiki wants to customize how [[....]] syntax is resolved, so we are likely to maintain some sort of hook based around that syntax.

I removed the $expansionDepth parameter entirely from both hooks. During testing it turned out to be returning mostly random numbers, depending on a lot of factors, that made it unusable in production.
The extension does not rely on this parameter anymore.

In T220765#5212213, @Ciencia_Al_Poder wrote:

Note that storing all threads, or all messages of a thread, on a single slot, will make conflict resolution harder, depending on how the edit is handled (2 or more users adding or editing comments of the same thread)

Nope, after investigating it I concluded I have no idea how to fix it. Looks like solving it elegantly would require a small redesign of how UW handles configuration from LocalSettings.php and campaigns. Halp.

While trying to do this, I encountered a serious bug with how UploadWizard parses its configuration settings, I will have to fix that first. See task T228771 for details.

On a second thought, my proposed solution isn't a very good one. The tutorial can be customized per-campaign and restricting it to a single MW message would mean losing that feature.

Done: https://www.mediawiki.org/wiki/Extension:THICC

Here you go folks

I tested it on the latest MW 1.34.0-alpha 12th May 2019 with UploadWizard 1.5.0 12th May 2019 and on stable MW 1.32.0 with UploadWizard 1.5.0 14th October 2018. The problem exists on both of these version configurations.