Rather an edge case, but… :-)
Today, for the security release, @Reedy push ~50 pre-C+2'ed patches (~10 patches to master+four release branches); half of these were force-merged, so the Test and Gate-and-Submit pipelines were both unused, and the other half definitely didn't need Test as well. Spending 10 minutes manually killing jenkins jobs to try to get CI to focus on the patches that were actually needing it was a pain.
Not a priority, just a gripe.
Well, I C+2,V+2'd,submit 20-25 patches total (REL1_27 and REL1_30), because we knew the patches wouldn't pass CI (due to the node bumps and not backporting the fixes due to them being EOL), and I didn't just want to force push to the branches (so there was still an entry in gerrit)
So this meant, all these patches created test and gate-and-submit tests that we honestly didn't care about the result of.
So to try and save some time, we killed as many tests as we could for jobs we really didn't care about, to try and alleviate the already overloaded queue
So as James says, not a priority, but would be useful in these sorts of cases
For the security release case, which I think is really the only case we want to support skipping CI for, I think we could have some topic/hashtag (if zuul supports those) or a pseudo-header in the commit message (e.g. Wikimedia-CI: skip) that zuul filters on maybe with an email whitelist to approved releasers to not queue any jobs for.
The proposed solution in the task title compromises the performance of everyone's patches just for this one edge case, which I don't think is a good idea.