I have to shift my brain into totally different modes between programming and reviewing/testing/version-controlling, and git add -p is an important tool. Maybe you're disciplined enough to keep a queue of everything you'd like to do in your head at once, and only stick to one task at a time, and shift into review/test/commit mode between quantized chunks. Me, I just go in, hack for a bit, and when I run out of ideas, I shift modes, read the git diff, break out my work into chunks, and then add -p/stash/test/review/commit chunk by chunk.

If you want all of my commits to be functionally and semantically separate and individually tested, I can give that to you. git-add -p is just an interface between that well-disciplined software-engineering expectation and what my brain actually does when it gets into flow.

It means you keep your original history around & build a new one which breaks the code changes into functional chunks.

Rewriting your existing history with git rebase -i is fine until it goes horribly wrong & you have to go groveling through the reflog to work out which commits you need to rescue in order to retrieve your lost work.

I don't see that. Keeping your original history around is a function of doing cleanup on a separate branch. It has nothing to do with how that cleanup is achieved.

Rewriting your existing history with git reset can also go horribly wrong, which is why it's done on a separate branch here.