Then, later, you might get an idea on how to improve your previous change. You go and amend it. And so forth. Eventually, you have a set of changes that's ready to be committed and which you have used locally for long enough that you can tell it doesn't break anything obvious. Then, you go through the code review, and finally push the changes.
With a completely centralized system, you have one of the following going on:
A. You don't actually do code reviews before pushing changes, and trunk is broken half the time.
B. You wait all the time on your changes being reviewed, and you can't commit them until they have been.
C. You revert to tarballs and diffs for dealing with different changesets.
I was forcibly pushed into using git from svn, but now I'd never go back: its simply so much easier to say "OK, I'm done with this change, I'll commit it!" and not have to wait for everyone else to be in the office/online/available to look at the changes before I do so.
This is especially important when dealing with separate changesets that necessary depend on each other, where you can't merely make a new branch for the new change because it requires the old changes.