Isn't this basically what @suffusion_of_yellow's EFFP Helper is a workaround for currently?

Yes. And the workaround is, like all workarounds, imperfect and this task is requesting it be made perfect.

Makes sense, but I think that abuse filter helpers and admins should also be allowed to "un-disallow" an edit then, not only abuse filter managers.

I disagree. Abuse filter helper is a read-only right and should stay that way. Admins involved in this area might as well self-grant EFM.

In any event this task (which is unlikely to be worked on anytime soon - I don't plan to work on it myself) is about adding the technical ability for anyone (other than technically XML importers who already can) to do it. Once that's done enwiki can decide who to grant the permissions following local consensus processes.

There is a flaw with this proposal. Specifically, the part that says "if there's no edit conflict" cannot be asserted done in an automatic way.

Edit conflict is determined simply based on proximity of the segments edited by two different edits, not semantically. It is possible that between when an edit was disallowed by AbuseFilter, and when the edit is subsequently being "reapplied", other non-adjacent sections of the article are edited in such way that would change the meaning of section originally intended to be edited by the disallowed edit. Therefore, re-applying the disallowed edit would result in a meaning other than what the editor intended. Because in this proposal, the edit is re-applied either automatically or by request of another user (e.g., a sysop), and yet the article history would show the original editor as the person who made the edit, there will be diffusion of accountability.

An alternative proposal could be one where the abusefilter manager would "un-disallow" an edit, but that then means the original editor would have a way to re-apply the edit, putting the accountability back with them. However, this also has some problems. First, we would need to create a UX that would show the user the changes in the article since their original attempted edit (our current "diff" would not do that, as it only shows changes compared to the latest version that is being edited). Second, what if the user decides they want to also make a slight change to their edit, e.g. to account for the other changes that happened in between? On one hand, this would be a good idea because the user would have the opportunity to make a "meaningful" edit rather than re-applying an edit that is now out of context and having to make a second edit to adjust it. On the other hand, the modification may itself trigger the same edit filter and be disallowed.

I am inclined to say that this request should be declined due to not being practical.

At the very least you could do it if there are no changes since the attempted disallow, which would probably be decently common.

But the scenario you're worried about is no different than any other case with automatic merging of edit conflicts.

An alternative might be to have the the AbuseFilter user make the edit, and name both the disallowed user and the EFM in the edit summary.

That's just worse IMO.

Implementation suggestion for anyone who cares to implement it: make disallow a ReversibleConsequence, and add it to the hardcoded list at https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/f7e39afb2cf7c5e9d67f5f0d17b58f59ddf3cd88/includes/View/AbuseFilterViewRevert.php#L300.

It's tempting, but I wouldn't recommend it. AbuseFilter/revert interface is for mass undoing actions (unless we have T335649) and does not give admins much control beyond that (it's also bound to the abusefilter-revert right).