You make an interesting point, and I'd like to suggest an alternative lens to view it from, as a thought experiment. Let's say company X values work that benefits company X, and that's why they hired you and pay your salary. You've given two examples of promotion rationale, one in which you clearly and objectively demonstrated the impact of the work. And the other, speculative, as you say. Now speculative implies not necessarily real -- it's possible that your guess about how much it will probably save could turn out to be wrong. If you don't have a way to measure this, how do you know that it's the case? It feels good to refactor the code, but just consider for a moment the possibility that you could travel through time and see the future results of current behavior. What if you fast-forward and discover that refactoring that code had no benefit? Now return to the current time: is it actually worth doing? If you're spending time refactoring that code at the expense of developing the feature? Maybe this is why company X prefers to promote people based on actual impact rather than speculation.
Perhaps another solution here is to look for ways to measure the impact of that refactoring. Surely your bugs go through some kind of bug tracker, and you would be able to count the before and the after? Is there no line on no graph anywhere that shows an improvement attributable to the refactoring? Can peers at least speak to how crappy the code was before and how much easier it is to work with now? Perhaps the new employee got up to speed in record time because of it? If, at the end of the day, there's absolutely no way to show that this work was valuable, then perhaps... and here's the part we don't like to think about as engineers... perhaps it wasn't all that valuable. Here's the part we like to think about even worse: you could spend 6 months of your career working really hard on something that turns out to be a dud. And it may be entirely rational that you don't get a promotion on the back of that work.
I'm not saying this is how Google works, or describing any particular situation, but I find it valuable to consider different points of view.
To me, this thinking seems like a sure way to get an unmaintanable mess. Now, just polishing a codebase forever without adding any features obviously isn't a valuable way to spend time. But the difference between changing one value in one configuration struct and it having no unforseen side effects and having to go trough multiple classes and reasoning about possible thread races etc. Can make a huge difference in feature adding time. However, how do we measure this?
If all features were equal, like widget production, we'd definitely be able to prove or disprove the productivity boost, but I haven't ever worked in a context where this is the case. There's no guarantee that feature implementation time will go down, maybe it did just not go up as much as it would otherwise, maybe people manage to make more useful features in the future, or at least not as much less useful as they would have been (we would expect utility/feature to go down as a system matures)
When I worked in a two-person team it was easier, of course, the time I spent on improving the code base I soon got back when I had to implement new functionality on a short deadline, this reflected well on me in performance reviews. The problem in a larger team is that it might be someone else who is able to implement a feature quickly due to my improvements.
My guess is that we should be lucky that there are guys like the OP who naively spend time on "low impact" code improvements even though they might not reap the rewards. Without them we would only have people doing the bare minimum to implement new features with a big ball of spaghetti as a result, where projects are abandoned just because no one is willing to maintain them any more. (does this sound like some company we know?)
I guess what I'm describing is that we might end up with a prisoners dilemma situation, where optimising for short term measurability represents defection.
You make an interesting point, and I'd like to suggest an alternative lens to view it from, as a thought experiment. Let's say company X values work that benefits company X, and that's why they hired you and pay your salary. You've given two examples of promotion rationale, one in which you clearly and objectively demonstrated the impact of the work. And the other, speculative, as you say. Now speculative implies not necessarily real -- it's possible that your guess about how much it will probably save could turn out to be wrong. If you don't have a way to measure this, how do you know that it's the case? It feels good to refactor the code, but just consider for a moment the possibility that you could travel through time and see the future results of current behavior. What if you fast-forward and discover that refactoring that code had no benefit? Now return to the current time: is it actually worth doing? If you're spending time refactoring that code at the expense of developing the feature? Maybe this is why company X prefers to promote people based on actual impact rather than speculation.
Perhaps another solution here is to look for ways to measure the impact of that refactoring. Surely your bugs go through some kind of bug tracker, and you would be able to count the before and the after? Is there no line on no graph anywhere that shows an improvement attributable to the refactoring? Can peers at least speak to how crappy the code was before and how much easier it is to work with now? Perhaps the new employee got up to speed in record time because of it? If, at the end of the day, there's absolutely no way to show that this work was valuable, then perhaps... and here's the part we don't like to think about as engineers... perhaps it wasn't all that valuable. Here's the part we like to think about even worse: you could spend 6 months of your career working really hard on something that turns out to be a dud. And it may be entirely rational that you don't get a promotion on the back of that work.
I'm not saying this is how Google works, or describing any particular situation, but I find it valuable to consider different points of view.