In my opinion, one of the top criteria for a good developer is that they don't fear making changes. If a function has changed purposed, a good programmer will rename that function even if it's across hundreds of files.
A poor programmer will see that as wasted effort and not do it.
From my experience working with a good infrastructure team, good system administrators do the same sort of thing. It's easy to not change names but in 10 years you have no idea what you're looking at. Our team is constantly moving stuff around and renaming things when it makes sense to do it.
To me the most painful style of wasted effort is that of renaming an entity and all of the connection points to other services, and documentation, wikis, slack channel names, email lists, etc. because the name is causing cognitive dissonance.
That's the trade off. You have to decide whether or not it's worth it. But if you never do it, then you end up a with a system where nothing means what it says and that's awful.
I feel the best time to rename something is as early in the development process as possible. Because the longer something is wrong the more entrenched it becomes.
I guess it can be subjective whether the cognitive dissonance isn’t more painful, but it certainly can be a constant strain. This is especially the case if the term in question is a software engineering term you also want to use in its regular meaning. “Cute” names at least avoid that situation.
A poor programmer will see that as wasted effort and not do it.
From my experience working with a good infrastructure team, good system administrators do the same sort of thing. It's easy to not change names but in 10 years you have no idea what you're looking at. Our team is constantly moving stuff around and renaming things when it makes sense to do it.