Yes, because Iterators.partition does not match the behavior of @threads. After dividing a collection into partitions of equal size, Iterators.partition will create one more partition with the remainder of the collection. On the other hand, @threads takes the remainder of the collection and evenly distributes it among the existing partitions. So, @threads (or my custom partition function) ends up with nthreads() partitions of approximately equal size, whereas Iterators.partition ends up with nthreads() partitions of equal size plus another, smaller partition (or nthreads() - 1 partitions of equal size plus another, smaller partition).
For splitting work across threads, the @threads behavior is more efficient because it keeps the loads of all threads more equal, and you won't accidentally have one more partition than the number of threads you're using.
Plus, I personally find specifying the number of partitions easier to reason about than specifying the number of elements in each partition. (To me, this is similar to specifying a range with the length of the range rather than the step size.)