I've humbled and have been humbled before because sometimes what looks like an ugly, unclean solution is the correct solution. There might be weird edge cases in the system that you catch, but the person doing the rewriting doesn't see until they push the code out and it breaks something in an entirely different part of the codebase.
That's the biggest reason why you should always, always discuss those changes with your coworkers first instead of going cowboy on it.
Or have tests. If your push comes with tests and I reduce the code by half while still passing all of them it means that 1). you didn't actually test everything you've done 2). you didn't write code as well as you should have 3). I'm an idiot and made the code less robust.
1) happens all the time. 2) happens some of the time 3). happens as often as 2.
This seems more like a post-hoc justification than any real rationale for change. There's nothing stopping your new code from introducing new testing requirements that weren't needed for the original code and it sounds like for 1) it could be equally a case of you blaming another developer when its actually 3) that occurred.
This also assumes that everything is actually testable, sometimes you write unclean code because the underlying framework or module you're working with has an entirely separate issue that you have to work around. Which again, might not show up because your work around code sidesteps the underlying issues.
This all boils down to the fact that you should just talk to the developer and see what they had in mind rather than assuming that you're right and they're wrong by rewriting it yourself.
That's the biggest reason why you should always, always discuss those changes with your coworkers first instead of going cowboy on it.