If someone has a clean commit that is a district unit of functionally and passes all tests, why would that not have simply been committed as an independent change prior to continuing work? The only way a consistent unit of code would exist to revert is by stacking it on such a change.

I am not sure I have ever encountered a situation where targeting a single commit to revert would have actually worked(from a rebased merge). I would go as far as saying that git revert should be a nuclear option reserved for only the worst of situations(urgent PE hotfix?). If something is worth reverting and was missed by the engineer and the reviewers, it seems the like fix should also atomically contain the explaination with a test to prove the issue was fixed. Because of this mentality, I believe it has been several years since I have seen a 'revert' in the wild.

Maybe I am alone in the industry with my opinion. However, I have seen the same patterns unfold on many teams. ...A lot of concerns with switching to a dead simple git workflow that fade almost immediately after trying it. Just my experience (backend batch jobs, applications, and rest services).