I think it's a sane discussion to have. There are pros and cons for both answers, and we probably need to be consistent about it to have the project being "fair" to all contributors.
So all what I want is just to keep git history clean from non functional mass changes. I do not see how accepting non functional mass changes can attract more people.
Looking at the history is an occasional activity; while looking at the current code is something many people do daily (I think I spend 60% of my day reading code, while I look a project history a few times a month).
So I personally am in the opinion that the state of current code is more important in term of maintenance than the state of the history, and that someone contributing such a mass change to improve current code is doing something good for the present and future of the project by making the code feel more welcoming and more maintainable (and probably better technically in case of isEmpty vs size).
For the history, things like git bisect can sometimes be an alternative where you need a git blame.
Of course, my comment applies only when the change is technically safe. For cases where the change introduce risk, we should first evaluate the risk and not merge risky parts unless they're proven to be fine.
