One of the most fascinating things I learned when I read Martin Fowler's Refactoring book was how many types of refactors come in pairs, one that is the exact reverse of the other. There aren't any refactors that are universally beneficial. It always depends on the circumstances, and often other developers are aware of circumstances you aren't.
Sometimes the merits of a refactor are not immediately obvious, and you need to make your case. That case shouldn't be something like "DDD says" unless the reviewers are very familiar with DDD. It should be something like, "The old name makes it difficult to tell this concept apart from this other one. This new name is closer to how our customers would refer to this concept in their requirements. This will make it easier for me to make x change I'm planning in a subsequent pull request."
In my experience, most developers with concerns like yours are not making bad changes, they just aren't good at selling them.
Putting it in a separate pull request also has a good reason. It's not just for the sake of bureaucracy. It's easier to review 10 pull requests than one big pull request that should have been 10. If I see a pull request that renames a class, and the author has made a good case for it, I can quickly glance through the changes and see "yep, this is just that rename," and hit approve.
Alternately, if you've stated your reasons well and I'm aware of circumstances you aren't, it's easier for me to correct you. "While your term is more popular broadly, in our particular industry the existing term is more common, for x historical reason." And I can reject the pull request without rejecting other changes I don't disagree with, or feeling like I'm going to make you feel bad.
If that rename is mixed with other changes, I have to painstakingly, line by line, determine if this line changed due to the rename or to something else, or both. If I have objections about the refactor, I may not want to look petty picking on a rename when there are meatier issues to consider, so I have to balance my review. That extra mental effort makes me annoyed about the rename, even if I would have supported it in a separate pull request. It's irrational, but that's how human brains work, and that's one reason why we make the rule about refactors in separate pull requests. It also feels more important if someone took the time to single it out.
In other words, there are not just technical factors to consider, there are human factors to consider, and you will be more successful if you find ways to help other developers be happy about your changes.