This strikes me as some kind of terrible vicious cycle: tradeoffs against performance (towards build speed) were made > users got used to slower software > users unconsciously prefer/select for slower software.
When you do get to use it, using performant software is a really great experience, so how to we train users to appreciate this?
Sometimes companies do decide to make speed a priority, and earn literally hundreds of billions of dollars off it. One of Google's key features over Yahoo+Altavista was that it loaded instantly; they cut out all the crap from the homepage so you could get yourself to a result in under a second.
Ditto BitTorrent clients like uTorrent and Transmission; the first generation of BitTorrent clients were written in Python or Java, and felt like it. When users started complaining about how they would lock up your machine, somebody actually bothered to write one in highly-optimized native Win32 C, with no frameworks.
You have to understand what the customer is optimizing for though. Someone standing at an ATM is optimizing for confidence, not speed; they already took the time to drive to the ATM, so depositing their check in 1 second vs. 10 seconds doesn't matter when the whole trip takes them 10 minutes. Someone who's responsible for depositing 1000s of checks for a major business, using an office scanner, cares a lot. But I really doubt that industrial-strength check cashing apps put a sleep() statement when scanning the checks.
When you do get to use it, using performant software is a really great experience, so how to we train users to appreciate this?