It occurred to me today that I haven't heard the word "killer app" used in a while. I think that's interesting, because I used to hear it all the time. It tended to mean (as the wikipedia will tell you) an application which was so compelling that it would cause someone to buy all the necessary infrastructure to run it.
Though the term seems to have vanished from my side of the world, some of what that term alluded to remains quite important. I remember talking to one developer in Beijing, and asking why he used Windows rather than some version of Linux. His answer was that one big reason is that there was a special IM client he used with friends that only ran on Windows. I do some volunteering to maintain the technology infrastructure at a nearby charity, and they're all Windows-based. I would like to have been able to recommend that they use something else. In theory this might have been doable for many of them. However, many of them also were quite invested in a database application built on top of Lotus Approach. Switching to another OS would have meant finding some way to get that ported.
These examples aren't quite "killer app" examples, as that term always seemed to mean a novel and exciting application, and in these cases, these aren't novel apps. They're pretty mundane, actually. But, they are useful or necessary apps for these people, and when all other things are equal, it is these critical apps which decide the OS.
I'll tie all this back to usability by pointing out that it is rarely a particular feature which creates a critical app. Nor is it usually a particular bit of "ease of use". Usually, it is some critical need which the software either solves or creates and solves which compells a person to decide the rest of their computing environment. When doing user research for your product, it is certainly worthwhile to determine what the critical needs that your customers have, and how that will influence their adoption of your software.