On the contrary, it absolutely can be, in both directions.
Software can absolutely be "feature complete", and in the case of many products it would have been an improvement to say "we're done now" and switch from developing new features to maintenance-only mode, dealing only with API changes and new laws.
Some examples of where it should be "done" by some point include smart TVs and smart lightbulbs. I'm also old enough to remember the era of games where patches were rare and small, unlike the current experience of having to wait for Steam to install updates almost every day, and only then will allow me to see if the game I want to play and which worked yesterday now has a mandatory update that I also have to wait for (which is less often but still often enough to be annoying).
Even with MacOS, while I absolutely do appreciate all the behind the scenes stuff regarding security and so on, the last time I appreciated what they did with the UI in an update, the version branding scheme was still to name releases after cats.
Even as an iOS developer, although I can see what they're trying to do with SwiftUI, I find it worse than UIKit in basically every regard because the "magic" keeps not working and the "problem" it tried to solve was never (for me) a problem; with concurrency, they went from GCD to Combine which IMO was a step back, before going to async/await.
"Too many features" is also a problem for the developers, as it leads to them duplicating work. For example, the background sounds feature on my phone and the one on my HomePod each has its own list of sounds, they're not just two interfaces to the same underlying app even though the HomePod's OS is a fork of tvOS which is a fork of iOS.
(The other way around, the home I grew up in is now about twice the size it was when my parents bought it around 1970, judging from the Google areal view).
