I think a sensible rule of thumb would be "split up patches where you can," for the reasons you specify. But there are some places where it either just doesn't make sense, or worse makes things more difficult, and it would be great if core committers could keep that in mind when making these requests.
I see a tension between two principles: (1) we break up patches, and (2) each patch must be mature and complete before it's applied. These come into conflict when we have a large problem that needs a large solution. Yes, we can break the problem up, but each piece (patch) necessarily will be incomplete and immature until they're all done. Maybe to successfully break up large improvements we need an approach something like: (a) Signoff in principle in advance from a core committer: no guarantees, but the proposal seems the right general direction. And commitment from the group leading the change: we will follow through on cleanup after the patches go in. (b) Direction and agreement to break particular pieces off. (c) A relaxed readiness criterion for the pieces (individual patches) as they're applied. These are steps toward a goal. (d) Completion patches at the end to integrate the pieces. And I agree with both Neil and Angie. Some things are cleaner split off. And some things are so integral that they need at least a core that's large, though beyond that, sure, details can be hived off to be done separately/later.