There is a particular failure mode in FOSS though - normally in businesses, prioritizing new features is done on the basis of how it will ultimately affect revenue (or reduce costs, simplify things, reduce maintenance burden - still money at the end of the day). For those FOSS projects that are open to new features from randoms, those individuals are mostly adding features they individually want, and the amount of investment in those features is limited mostly by their level of personal interest. So you end up with a set of features that is more stochastically chosen, and some unimportant or minor features may have a huge amount of complexity/configurability/feature-specific code because one person needed it.
Either way, I don't believe that polish and FOSS feature abundance necessarily have to be at odds; it just means that the project in question needs to have a process for developing new features to production-readiness. This can take form in any number of ways, for example using feature flags to keep things that aren't yet fully baked enabled only in beta/alpha builds — people happy with a less polished experience can use betas until the feature they need is ready for primetime while the greater userbase gets a better user experience.