I'm not saying never refactor, but it's often done prematurely.

> It means that all future developers will have to spend a lot of time to understand complex code that could be simpler.

Code that's complex is often complex because the domain it's written for is complex. I've heard it called incidental complexity. Could you write it more simply? Potentially, but how sure are you that you're not about to get rid of edge case handling or important features?

Tests only work if you're sure you understand the requirements well enough to write the test. If you're at that point of understanding in the platform, you've probably got a good idea of whether or not you should refactor.

> Another reason to refactor is that you want to give new developers the satisfaction of "owning" part of the code. I read an article on software engineering at Google saying that it was ok if some parts were rewritten over and over.

I think it's an attitude software learned while it's been flooded with easy money, where the tangible cost of constantly throwing away code is never really considered. Code is never considered an asset, but had you built a tractor for a company they would definitely want to know why you want to build a brand new tractor when the old one is working fine.

I have mostly worked in agency environments, and as such cost is always part of the conversation. Often the only people who want the refactor is the developers. It doesn't provide any value to the business. I often do advocate for a refactor for some of the reasons you mention, but to get client buy in you need to provide some real value, and when you have to think about that it quickly discovers whether or not your refactor is frivolous.