This looks like a nice tool, but I agree with GP because as a reviewer I don't care about a "clean" commit history in a branch I'm reviewing. I care about what's changed, and imo the request description/annotations can describe that in plain language better than a commit history can tell a story.
You need to look further ahead than that though. A sane git history makes debugging much easier. When you bisect your way to a problem area, sure is nice when the suspect lines of code fall into a 10 line change commit with a nice message and body providing context. I’ll let it slide if the PR/MR has a lot of good context, because it’s trivial to link those back to commits/lines.
I also think we should be thinking more long-term. How understandable is the history when you're trying to figure out why something changed? I usually try to tell the story of what changes are being made rather than treating every clump of commits as a "PR" that's just going to be squashed together anyway. I think a lot of valuable information is lost by doing that. But I realize that that train has left the station for most, so I'll just shut up now.
I've always seen the clean commit stuff as a "I'm a junior and need to figure out how to logicaly lay out my thoughts" and push people away from uni commit model. clean commit purists take it a bit too far