The reasons for the previous rejections still hold:  more tools make the overall toolset harder to use, not being a primitive operation, dearth of real-world use-cases, not being prevalent in other functional languages, easily expressible with existing tools, non-consensus on what to do with odd-sizes, lack of adoption of the published recipe, and a hard-to-guess function name.

In addition to previously listed reasons, I have vague feelings that this isn't the right thing to do.  The feelings are in-part based on poor user experience with itertools.groupby(), a function that developers said they wanted but ended-up being awkward to fit into real applications, confusing to some users, and rarely used in practice.
  
Another source of misgivings is that iterators may not be the right tool for this kind of task.  For example, when partitioning data into subgroups for a map/reduce operation, iterators won't help because they are evaluated serially which precludes any chance of parallelization.  Even in cases of serial processing such reading blocks from a socket, the chunks iterator would be useless or awkward (i.e. we need more versatility than iterator.next() to manage the control-flow, time-outs, out-of-band control, separating headers from content, etc.)  In other words, I have a sense that the generic concept of "break data into chunks" tends to occur is situations where the iterator protocol would be at odds with a clean solution.

That said, I'll leave this open for a while and do my best to try to warm-up to it.  Your recurring enthusiasm for it is a positive point.  Another is its the faint resemblance to a numpy reshape operation.

P.S.  In prior discussions, the only real use case that ever surfaced was printing long sequences of data across multiple columns.  Even that use case was suspect because the desired order is typically in column-major order (for example, look at the output of the *nix "ls" command).