You can use "git rebase -i" to remove the unwanted commit from the history.
Git rebase is very powerful, definitely worth mastering.
True, but now you're forcing the user to make a bunch of yes/no decisions about what should be kept and what should be discarded. If you make the wrong decision at any point you can lose your work! (I can't remember off the top of my head if Git keeps a tag for the pre-rebase state, but if so that's a lot of clutter that would accumulate over time). And the VCS still hasn't helped you determine what lines of development are independent of each other.
The workflow I am envisioning lets you visually see your working directory as a bunch of independent lines of development. Before you do anything, you can see that your coworker's change is independent of your own changes (because the VCS has analyzed the changes and knows that this is so), which gives you confidence that you can easily remove his change without affecting any of your changes. Then you have the option to simply remove his change, and it's gone.
Sometimes you just don't have time to do clean commits (by committing only relevant changes with "git add -p"), or you fix something later which was logically part of a previous commit.
Being able to curate the commit history or your local clone, besides pure aesthetics, allows you to present a given contribution to other team members so that they can better understand what you wanted to do and perhaps review the commits.