The problem with this analogy is that it makes sense to work with lower quality materials in real life, because the cost savings scale with the number if units you produce.
With web content it’s the exact opposite. Every time you are a bit lazy, and add another mushy, poorly optimized dependency, the cost is paid by every one of your users.
The better analogy is that the web is like an assembly line that serves content. Do you want wooden equipment with poor tolerances making up that assembly line which takes twice as long and occasionally dumps parts on the ground, or do you want a well-optimized system working at peak efficiency?
A lot of the problems with web development have nothing to do with time to market. There's no technical reason you could not have a toolset which is just as easy to use, but far more performant.
That would explain why they continue to be used after initial adoption. It doesn't explain why they were initially chosen if there were better options using something that already existed.
History and inertia also are nearly synonymous with "easier to use" in this context.
With web content it’s the exact opposite. Every time you are a bit lazy, and add another mushy, poorly optimized dependency, the cost is paid by every one of your users.
The better analogy is that the web is like an assembly line that serves content. Do you want wooden equipment with poor tolerances making up that assembly line which takes twice as long and occasionally dumps parts on the ground, or do you want a well-optimized system working at peak efficiency?