Even at large companies, there's often pressure to deliver quickly and often. Throwing out large parts of the UI and starting over to please the marketing department is SOP at a lot of places too.
If it were a normal desktop application, they would throw a 30-man team at the problem, but because "it's just a web page/site", it'll be a team of 3-5 people and the time tables will be pushed up.
When you combine these problems, it's no wonder that a lot of JS devs view almost anything that isn't a new deliverable as overly-optimized.
It's especially ironic considering the source of the phrase:
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. -Knuth
It's like that cliche "it's only a few bad apples" from the proverb "a few bad apples spoils the bunch."
