Why would you want to understand what was going on? Maybe for fixing a bug, maybe for working out why a seemingly useless change was necessary, maybe to understand the context of a code review building on previously merged branches, or maybe just because you need to catch up on what happened while you were gone.
If that's not important to you, then don't bother, but it can be hard to understand what you're missing until you've tried both ways.
Really ? To me the need for checking history is extremely common. Many projects have multiple delivery, maintenance and other branches, patches need to be applied here and there. Bugs are found and the versions affected needs to be identified.
Not maintaining a clean history would cause severe pain.
Do you automate it?
Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?
Obviously, for any old arbitrary project, there's going to be limits to what you can ask your contributors to conform to before they just leave, but we're discussing "Best Practices"[1] here.
I think these articles are useful because they spread the knowledge of "How To Be A Good Contributor"... for free.
[1] Ugh. Not a term I like, but really this is almost always(!) the best way to do it.
Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy.
I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute.
I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success.
This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.
I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. If you could write a document that teaches others how to write clean code, what would it contain? How long would it be? How complex would it be? I'm betting you've built up a repertoire of wisdom on writing easy to read code, and I'm betting that document would be quite long, especially if you furnished it with examples.
I think it's the same for commit history. If you're rebasing, then you're probably trying to shoot for a clean history that other humans can understand. Maintaining a clean history can be just as hard (and just as rewarding) as maintaining clean code.