At my last company the culture was to break up work into easily understood chunks, so the same code would have probably been 5-10 diffs of 100-1000 lines each. I thought it really helped make reviews much more effective and quicker. It took practice to learn how to effectively break up my changes like this but now I can't imagine doing it any other way.
I find it impossible to truly understand whats going on when looking at a set of changes that are bigger than around 1000 lines (not including unit tests.) Apparently people block out 2-3 hour chunks on their calendar to review this person's code.
Is it reasonable to ask this person to break up their work so its easier to review, or am I the outlier and should I just try to get better at reading and reviewing very large diffs?
So I've done that... once. I don't think I've done anything like it any other time.
Maybe a way to do this is to say that yes, you can do a code review that large, but only with justification, and the justification has to be accepted by the reviewer, not just by the change author (or the author's manager).
The original dev would have to break their work up, it could also mean that the tasks are too large. Generally we would code review each task, and a task would never require 1000 lines of code!