As a programmer and Unix loyalist, I hate complexity and redundancy with a passion. I want to do things The One Right Way. But I wanna make an argument that including unnecessary features in software or alternative ways to do the same thing is bad for a multitude of practical reasons, not just the aesthetic appeal of simplicity.
Every feature takes time to learn.
As an extension of the above, less important features impede your learning of the more important ones, because you don't always know which features are the most important until you learn them. The perception of a lot of features can even result in users never investing the effort to learn them all, like I did when I played Starcraft.
When you find out two ways of doing the same thing that aren't marked as such, you're likely to doubt your understanding of the features. This can cost time as you check to make sure there isn't a difference.
The more features, even if they overlap in functionality, the harder it is to make sure none of them have bugs. It gets exponentially more difficult to anticipate how they might all be used together and test everything.
This may not apply to all software projects, but for languages, standards or frameworks, more features means different developers might come up with different ways of accomplishing the same tasks. This can lead to confusion when they work together, and in the best case that confusion will cost precious time. (At worst it can cause conflict between developers.)
Another thing only relevant to such projects: If it's a project that other projects might have to go out of their way to support (formats and protocols are the best examples), more features raises the cost of implementing support. For example, if headers are supposed to be case-insensitive, then applications that use the protocol have to do case conversion when they compare strings. At best this wastes other people's time and inflates their code; at worst it gets overlooked and causes bugs and incompatibility.
Lastly, this doesn't concern the end user after it's done but the opportunity cost of development is massive. Any time the dev spends adding a feature that isn't needed is time not spent adding one that is needed, or fixing bugs, or doing something else of value.
Fun quote: "Normal people believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet."
I think a very underrated insight is this: features are costs. Functionality, defined as "the total extent to which the software makes things easier than they are without it", is good, and features, which are "the quantity of the means by which it provides functionality", are bad. Features are the cost you pay to implement functionality, and you better pick your battles (another excellent cat-v.org quote: "In programming the hard part isn't solving problems, but deciding what problems to solve."). It's like complexity versus depth in game design. You can have either one without the other. For example, Nano is an editor with relatively few features, but a lot of functionality.
git are programs that have tons of features, but achieve tons of functionality with them. QuickBooks is a program that has a staggering amount of features and achieves surprisingly little functionality.