You underestimate the passion with which the average front end developer hates CSS.

Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.

There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.

From my perspective a failure point is when companies do delegate time to make things correct, but demand results from the get go. Billing and tracking becomes weird for them if you work on infrastructure, design systems, component libraries, system design etc and you have nothing to show for after 6 months or a year. "But the future development will be super fast" doesn't fly past upper management unfortunately.

I would like to say I agree with the proposition of your post and your arguments, but as a web dev please don't mix the state of the web with what the median web dev considers a good UI/UX. We don't make the Jira tickets and if you have worked in a corporate environment you know very well that arguments like "but the UX/accessibility" hold very very little value in the context of most decisions.

On the other hand modern application of agile methodology is borderline ruinous for team productivity and most of the time exists for a specific stakeholder to feel less anxious rather than for a team member to raise a blocker or a dependency.

I work in a fairly big company and there is the notion of extracting people from their agile teams to have them work uninterrupted on large tech initiatives. Which is in my opinion a subtle way to signal that if you know what you want to build, agile methodology at least in the perverted way most companies apply it doesn’t work.