Editing will probably be used in practice (it's necessary for general bot processes that must apply to all content, for example removing references to deleted images).

However, you should stick to the priorities we discussed at the last meeting.

should we decline this and its subtickets?

I'll admit that I'm not an expert on bug management policy, but I've seen tasks (both bugs and enhancements) that are over a decade old, just sitting there completely forgotten, and I've even tried to fix a couple. The priorities of this and its subtasks are way off (they should probably be Lowest), but what exactly is the harm in leaving these open? Unless there's a plan to remove the existing Flow code from Pywikibot too (which would be a personal shame and a disappointment for anyone on Flow-enabled wikis who uses Pywikibot on talk pages), some of the features with tasks didn't end up being implemented in Flow, or the Pywikibot maintainers specifically say they don't want these to be implemented, I see no harm leaving these tasks open for someone to work on in the future.

Flow is not actively maintained anymore. It's being replaced by DiscussionTools. I'm not sure there would be value in adding support for something that is not maintained anymore.

I've always thought the beauty of FOSS was that any (working and non-buggy) patch could be added as long as there was someone to write it, someone to review it, someone to maintain it, and the possibility that someone could benefit from its inclusion, regardless of what the project managers saw its "value" to be. I guess we could always reopen one of them if someone ever gets around to posting a patch for review.

mediawiki and wikipedia-test still uses flow I guess. Therefore I don't see any reason to drop the task.