Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time.
You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"?
If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.
Did that typo fix introduce a bug? Maybe, maybe not, but many programmer hours have been wasted on incorrect single characters :)
If I were bisecting that repo, it's a lot easier and more useful to be able to point the finger at the one commit that actually changed the line, rather than having to parse the one monster squashed commit to find the one line that introduced the bug.
I tend to write documentation, so no, not a bug. But even then, there's lots of small code-review things that aren't always about bugs; project style, naming conventions, etc.
Furthermore, if this is a PR that's open, then the "bug" would have never even landed. So looking through history to "find what caused the bug" would have not even been a thing.
You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"?
If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.