I agree with you. To me, the action felt wrong when he described it. I wasn't sure why at first, but I think perhaps because the work was not in service to any actual task.

If he was in charge of writing the next piece of functionality for that code, it would be poor teamwork to completely refactor it without discussing the reasons for the design, but at least it would have been within his area of responsibility.

This is also the reason why I like having code review. The review would have been a good place to raise his concerns. They could have had their eventual conversion earlier, before feelings were hurt or wasted efforts were made. It would even help in the opposite case, where the author's code was legitimately poor and the reviewer had good suggestions.

It's not a panacea, but I find code review helpful. In my experience, review was the time when a lot of knowledge-sharing occurred. Some might feel that only senior developers should review, but as a junior I learned a lot about why the author made the choices they did. I learned how people expected the code to change, about language features or pitfalls, etc., and it helped me grow as a developer.

This actually happened to me, (and his rewrite didn’t even work!). Having witnessed this first-hand, I can say that the impact of the code change was absolutely dwarfed by the lost trust. Unsurprisingly, I would come to find out that this engineer had what I would call the opposite of soft skills, and the notion of a “this irks me so I rewrote your code” has become a giant red flag for me.

Did you lose trust because the code broke (a legit reason to lose trust) or because your code was changed without kissing your ring (a problem with you being too attached to your code emotionally).

Having a conversation and “kissing my ring” are not the same thing by a long shot, but that sure is a pretty strawman!