But let me push back a bit, too - a global find and replace on our entire source code would take maybe a couple hours. A substantial naming convention refactor would take maybe a couple of days.

The reason we don't do anything that aggressive is we don't trust ourselves to make the change correctly - not because it's actually a difficult change to make. Where our test coverage is where it should be, it's a perfectly safe change.

If my team tells me (in agreement with each other) that a change like that is necessary, my job is to go make time for them to get it done.

On the scale of requests my team has given me, a couple days to rename some variables is no big deal.

There's absolutely stuff I won't allow, as team manager, but flip flopping on variable naming is owned by the team, and I would allow it, within reason.

A couple fair-game manager reasons I might shut down a variable naming convention change are:

The test coverage on that part of the code doesn't inspire enough confidence to make any unnecessary changes. Improve the test coverage, and we will revisit.
(Hypothetically) We made two similar changes in recent memory, and as manager, this is affecting our team reputation. Let's make a plan to make this change in a way that does not impact our team reputation.

Anything short of those two scenarios, and - should my team present it to me in agreement - I go make the time for them to make the change.

A shorter version is: I'll discuss and do my best to support whatever my team wants to change - every two weeks. It's a small price to pay for some peace for 9 out of every 10 business days! (And honestly, it's a big part of my success formula.)