The people usually tasked with figuring these things out are new to the team. There can be all kinds of politics and interpersonal baggage with helping the new person with old configuration/ compilation/ deployment stuff.
Often, it'll take one of the legacy leads to step in and clean things up. By then, everyone's annoyed at the new person, and the failure of this effort will get saddled on their back for some time more.
I had this exact issue at a recent gig, and the application architect spent months poking at jenkins to get a clean build. Once he quit in frustration, one of the legacy leads re-engineered the whole thing, in a different language, in a few days.
Legacy lead was one of those "untouchables" in the eyes of the CEO, so there was no influencing him to help earlier, and his reticence cost us a good application architect.
To my mind, this is often a sign of a poisoned, political company culture. The work can be done, but there are non-technical reasons why progress can't be made, even by earnest effort.
No, it really, really isn’t. Maybe 1 in 1000 cases are like you describe but the rest is just that older engineers are harder to exploit.
If only there was a way for employees to rate their Manager instead of the other way.
Then again, I've been very selective in where I work. People like to bash the "culture" stereotype, but it's definitely something I consider when I'm looking for a job... you know, how people are expected to interact with other people, not whether there are ball pits and the like.
When you have a recognized long-term leader that doesn't need to constantly re-justify their involvement and existence (something akin to a BDFL), more collaborative group efforts can be fostered, and individual gamification is much less useful, because the people who know your behavior are going to be there for a long time and there is a lot of personal continuity. This system is, of course, not without its own type of flaws, but it doesn't have the same negative feedback incentives for individual contributors.
It's hard to get that long-term involvement in the tech industry specifically because the rapid rate of technical change limits career length and portability. Skills in language/system/framework X rarely retain marketability for more than 3-5 years. Most people don't have the stamina, interest, or whatever it is that's needed to keep up with the constant re-education and re-justification cycle into their 40s and 50s. They look for an out: early retirement, promotions into non-coding management positions, etc.
To the extent that individual metric gamification is higher-than-normal in tech, I would attribute most of it to the effect of shorter career tenures, both overall and at specific companies.
I think short-term thinking by superiors causes short-term behavior by reports.
If the management pays fairly, with fair raises, fair balance, fair acknowledgement of all kinds of work and not just the flashy stuff, most reports would focus on the right things, do their jobs well and not look to switch jobs all the time.
But if the management is always trying to escape giving promotions/raises, does not acknowledge the underlying effort to get something to production, only thinks about their own empires (basically short-term selfish thinking) it will cause a disproportionately high number of reports to behave the same aka look out for their selfish interests.
I am absolutely certain that top companies look to retain good players (top != stock price or market cap).
Managers absolutely don't seem to care about actually building a team and cultivating a culture of success.
Engineering managers are way way worse than Soccer managers in this regard.
I would put this all on the hiring processes right from how we hire engineers and managers and what gets a promotion. But unfortunately, our industry would rather remain blind.