(Junior developer here, looking to be convinced!)
But ideally interactive rebase before you push your PR and tidy up all those commits into larger topical ones.
Eg.
"DEV-1 - Write tests for widget X calculator" "DEV-1 - Implement widget X calculator" "DEV-1 - Refactor widget X factory service"
I think this is totally OK, just as long as you squash those all down before someone has to merge your PR.
> As long as each commit isn't causing a problem with CI/CD, and my pull request to master is well documented what is the value added of cleaning up commits?
Because it's hard to make sense of all those little commits later, so why keep them around? They're just noise with a very limited future value, and I don't want to have to sift through them in the future. It's basically impossible to clean up those kinds of messes once they get established in master, but it's very easy to contain them at pull request time.
I think it's really important to capture the context and indent behind changes. I may be weird, but when I'm fixing an issue, often try to find when it was introduced, which often provides really useful information for the fix. That's much harder to do if the commits aren't cohesive and the messages aren't descriptive.