Its interesting to think about - is feature creep uniquely in the domain of software? I don't think so. There is plenty of software that has been immune to it (think everyday developer tools, command line stuff, etc). Often the apps with the least amount of feature creep are the ones where they are bounded by the APIs they talk to, i.e. if the API (which they don't control) is static, they can't really add any more features.
Outside of software, we see a similar thing, a wrench (or spanner) hasn't gotten many new features, because the bolt that it turns isn't changing. the goal is roughly the same. The only appreciable changes have been in ergonomics, and even these are effectively static.
On the other hand, we have cars, which are suffering from so much feature creep it is unbelievable. every year, car engines get a little bit more efficient, but they also get heavier, bloated with more systems, infotainment, seat adjustments, window adjustments, etc.As a result, the efficiency of the improved powertrain seldom makes appreciable performance difference. (yes, there are outliers).
Cars then, might be the equivalent of "the ultimate app" which does everything for you, but loses sight of its purpose. Meanwhile, we have a long history of leaving single tools alone, and they tend to work great.
The trouble is that in the world of physical tools, the workflow changes/context switching between using one tool and then another is easy. Meanwhile, in software, feature creep ends up being the solution for poor context switching between apps. In an ideal world, working on an image in photoshop and then pixelmator, and then illustrator, and then publishing to wordpress would be as seamless as using a wrench, then a screwdriver, and then cleaning things up with a rag. Unfortunately, software interface constraints almost necessitate feature creep as the "simplest" way to add functionality, even when convoluted menus, hotkeys, and naming conventions obscure utility.