The problem is that it's often bundled with a similar but patently false and demonic idea---that the business and technical sides can be siloed without ill effect. They can't.
Someday someone will write a best-selling business book about how it's valuable for management to have technical expertise, and it'll have some catchy term like the "mangineer" or something.
I'm not the OP, but the point I think is that as long as you are content to be a "code monkey" (no disrespect meant at all, but that's what it sounds like) that just does what they're told for 40-50 hours per week, you can't expect to have any upward career growth.
Honestly, I'm not even sure how "upward career growth" could look in a company structured like that. I don't think I saw a single programmer in here who empowered himself with business domain knowledge to a degree where he could make meaningful contributions. I guess we're all comfortable with where we stand.
Where there's divergence is that engineers don't want to work for the business as a subordinate, or for compensation that justifies working on something less interesting or career-beneficial than what one would prefer.
Isn't that the inherent nature of a lot of the programming jobs, though? For example, I'm currently contracting at a e-commerce company. My day to day work is as you described - closing tickets that get assigned to me in the Sprint. I also suggest new tickets, but they're solely limited to technical issues (mostly addressing technical debt, trying out new technologies etc.).
Honestly, I wouldn't know how to suggest anything on the business side - I don't know a first thing about how the market we're in operates (except that it's very competitive), and we have a separate person (Product Manager) whose only job is to think of new features for our team to implement. I think that's the only arrangement that works for non-technical products, which is what vast majority of programmers work on.