Unless you're in a <10 headcount everyone-does-everything startup, by the time work reaches software engineering it's already been determined as having good business value. It's rarely a software engineer's job to challenge that determination unless new information emerges that wasn't factored into the original decision.
Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.
I think most engineering teams will have a "backlog" of tech debt. Some are things they want to do (the original implementation is icky but could be lived with for years until requirements change) and some will save the team hours per week in distractions/maintenance.
Being able to evaluate the actual impact of the "tech debt clean-up" and pick the one which helps the business will absolutely set you apart from your peers.
I think you massively underestimate the number of startups with product engineers.
It's becoming a much more popular approach with many high-performing startups, even up to the 250+ headcount tiers.
The execution by swe can still take 10 times longer depending on if you go with a proven, quick and dirty straightforward YAGNI solution vs reinventing the wheel in latest cool fad, with hundred layers of abstractions and configurations in beautifully crafted code in the most poetic rube goldberg machine you have ever seen.
Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.