I know that merging non-contiguous changesets at once may not be a good idea. However there is at least one situation in which merging non-contiguous changesets is (probably) not going to break anything: when there are no intervening changes on the affected individual files. (At least, it wouldn't break any worse than would a series of cherry-picked merges, checked in each time; and at least this way you would discover breakage before checking in).
For instance, let's say you have a Main and a Development branch. They start out identical (e.g. after a release). They have two files, foo.cs and bar.cs.
Alice makes a change in Development\foo.cs and checks it in as changeset #1001.
Bob makes a change in Development\bar.cs and checks it in as #1002.
Alice makes another change to Development\foo.cs and checks it in as #1003.
Now we could in theory merge both changes #1001 and #1003 from dev-to main in a single operation. If we try to merge at the branch level, dev-to-main, we will have to do it as two operations. In this simple, contrived example it's simple enough to merge the one file - but in the real world where there would be many files involved, it's not so simple.
Non-contiguous merging is one of the reasons given for why "merge by workitem" is not implemented in TFS.
