Many features don't require any user interaction or even knowledge, like passive error checks, and are easy to implement.
Some features can replace other features or even other entire systems, which would otherwise be much more work without the integration.
If I'm selling something on eBay, they do everything from communications to returns to payments to shipping calculations to keeping track of what I've bought and sold.
I sure wouldn't want to use some kind of modular thing where those were all separate parts.
Minimum effort spent on stuff nobody wants to do, minimum chance of mistakes, and minimum chance for getting into a state where you have to go back and redo earlier work is a more direct measure than just trying to avoid complexity.
That last one seems to be one of the usual very common points that make systems harder to use for people who aren't used to how software in general works, because it requires making the user define things as small pieces that the computer stacks up for you, rather than the real world process of stacking up stuff you wouldn't even think of as separate steps.
This is a common misconception.
It may happen to be true, but it does not have to be true.
What prevents rapid delivery is constraints, and naive, stupid or incompetent implementation (or requirements) for features that add more constraints.
Adding features in a way that aligns with existing constraints, or breaks existing constraints doesn’t have to be slow; just careful.
What kills software is “nothing can ever change once it’s in production”; ie. once a feature is live, it becomes a hard constraint that can never be altered or removed or changed because of user expectations.
It’s not the number of features; it’s the immobility and panic caused by the prospect of anything ever changing, which prevents you changing anything, except very very slowly.
That's hard for a business to turn down.
For enterprise SaaS, QBRs and contract renewals are the point where sales shares all the new features as part of the story as to why the company should continue being a customer.
A good interface organisation can hide the most complex features from most users. The lack of a feature might force users to use a different product; but if the software is confusing, or bloated, this is a problem with its how it's organised and the quality of its code, not with the number of features per se.
Often times a new feature is similar from the API perspective to pre-existing ones.
If that's the case either integration is simple, or you need to refactor the underlying API (which means that when you eventually get around to implementing the feature it (and similar future features) will integrate cleanly).
