The new CachingParser will have a shorter runtime, as previewed in T156095#5434572. This means that the current slow-filters system will mostly stop working, because the current threshold is too high. The problem is, cold-cache executions will still have runtimes similar to the ones we get now. So an idea could be to have two different thresholds, one for cold cache and one for warm cache. But that's not easy: runtime recording is handled inside AbuseFilterRunner, and is not limited to parsing, so the Parser doesn't have any knowledge about it.
Of note, for what concerns the runtime of all filters together, some of them may find warm cache, and others may not. Thus, the grouped runtime may be a little useful.
A possible implementation would be a (singleton?) profiler class, like I said in the comments of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/498978/, and the thresholds could be determined based on runtime in production. But for aggregated stats, there's not much I can think of.