Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk.
But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.
Lots of great points in this post from Craig Mod. It can be contrasted with the point that I don’t believe teams should prematurely optimize or prioritize application speed over meeting user needs.
However — if an application is noticeably slow, especially for common tasks, I will feel annoyed every time I use it. It feels as though a shortcut has been taken for the development team’s benefit (and not mine), or maybe they just don’t know what they’re doing.