One simple example:
commit 1: things work
commit 2: Feature X, regress
commit 4: Feature Y, break things by accident
commit 5: oops, fix commit #4
...
You land on commit 4 breaking your commit, but if #5 and #4 had been squashed then you would find commit #3 much more easily.
With a tiny history like this it's not a big deal, but with a larger one, it becomes an issue.
But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5?
Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem.
Try again. Squashing doesn't solve anything here.
I'm not saying all commits from a feature branch should be squashed to a single commit, but commits like "oops forgot to update header file" or some such are noise.
Rewriting history is about improving the signal-to-noise ratio. You may lose some signal (the Fossil argument against it), but if you lose more noise than signal it may be worth it (the git argument for it).