There are reasons against it but the real world is messy. Developers tend to commit things, recommit, undo, redo, move things around. Is this valuable history? It can be but I would say 99% of the time it's more valuable to have a good commit message about what was intended rather than what actually happened.
The idea of squash merge is to make the history clean from the get-go as you said.
I see 2-3 distinct final commits in that list there, ones that should be separate and not squashed into one:
* commit, recommit, undo (squash these ones, and depending on how much "undo" does could eliminate this entirely)
* redo (what exactly is in this one depends on how much "undo" did in the prior, and how the "redo" was done)
* move things around (feature is seemingly already working and this is a distinct separate "improve the code" step)
> Is this valuable history?
Keeping that last one separate is absurdly valuable when trying to figure out why the code acts the way it does, when a bug is reported later. A lot of bugs I encounter were in those steps when someone makes a simple typo moving the code around, and having it in the history makes it obvious it wasn't an intended change.