Around that time, whenever a new BlackBerry device was rebooted, it would take about 45 seconds for the OS to fully boot and become usable. I'm making up the actual times in this story because I can't remember the exact details now. Like in this video, the oldest devices would start up nearly instantly, but the boot sequence for modern devices was agonizing. Especially when you were an engineer trying to run a test that required rebooting the device!
One day, a pair of engineers finally became annoyed and curious enough to look into it and profile the problem. They found that a substantial portion of the boot time was spent parsing XML files that contained descriptions for device themes - that is, information about colors, icons, and text styles that users could choose from to customize their device. Something like a full 15 seconds was spent just on this one feature as part of the boot sequence!
So what happened? I suppose that no other engineers felt they had the responsibility or the time available to look into the long boot times until that point. But imagine being an engineer at a company like Microsoft, and one day saying to your manager or product manager: "Hey, can I spend a week on understanding why it takes a full second for Terminal to boot on Windows and see if we can speed that up?" How many managers are going to be enthusiastic about that when they're staring down a kanban board with enough tasks to fill 4 quarters?
The only reason these engineers at BlackBerry were able to look into the bootup times was because they didn't have to answer to anyone responsible for product. The team lead for this team at the time was "Engineer #2" at BlackBerry who had written all the apps for the first devices. His team was given permission to pursue whatever ideas or prototypes interested them, so they had the breathing room to chase leads like this that wouldn't necessarily pay off.
So part of the answer is that I don't think we as an industry are prioritizing performance. Once the performance is good enough, it's time to ship and move on to the next feature. But the other side is that we're building in more dynamic behaviour to our software. More customization, more flexibility, more behaviour that's defined at run-time. And this all probably makes software more useful and makes it easier for engineers to build more complex software. I think it's a similar kind of trade-off to choosing between python or Rust for a tool you're working on. What kind of performance do you need, and what kind of developer experience do you want?