If you're in a large organization, you're expecting other engineers to make sense of the work you're submitting. Anything that helps them here is a good thing (although it's always a tradeoff.)

The advice I try to live by, is that however messy my work was leading up to a PR, I make sure the end result is something somebody can review without additional context. Commits should have lengthy descriptions of changes that describe the "why" and "how" of a particular change, in a way that makes it easy to digest for a reviewer. Sometimes multiple commits make sense (like if you're renaming a module/class, put that in a single commit, then put the actual code change in the next one), sometimes they're not necessary. But it's worth it to put in the effort here if it means it helps a reviewer, IMO.

A clean history of small atomic commits is great for software archeology. That is going to be needed for debugging anything complex enough.