I’ve seen a lot of times where “business people” ask for a feature that sounds good but isn’t technically viable for any number of reasons. The devs not doing pushback would lead to similarly non-functional/broken stuff getting shipped.

The pushback doesn’t even need to be adversarial, just do some requirements engineering, figure out what they want and go “Okay, to implement X in the best possible way, we should do Y and avoid Z because of W.”

In the bridge analogy, the people who are asking for a specific design might not know that it’d collapse under its own weight and the engineers should look for the best solution.

There are environments where devs can't do that sort of requirements engineering and those are generally pretty dysfunctional - obviously you don't need that for every feature request, but it's nice to have that ability be available when needed.

On those sites you’re right: the approach was different, but not necessarily better. Tracking library bloat and marketing-driven design were reduced. But insane “security” constraints (e.g. “you have to stay on outdated revisions of this library” or “containers are not allowed on the backend, only bare metal”, no joke—constraints that led to significant increased security risk) and extremely user-hostile design practices increased, as well as there being an exceedingly long hurry-up-and-wait turnaround time for shipping important fixes/improvements.

Working on a safety/state-critical site isn’t a panacea, in other words.