That's great if there is one developer working on each component of the software. The moment you have people trying to do cross-component changes, or developing someone else's component, they don't just have to learn how the code works on a domain level, but also the features of the language the code is using.

The more recent editions of C++ do seem to support this idea. Things are at least better than when the trade off was taking advantage of C++ features (and more C++ like) or performance (and more C-like C++). The problem that there are only a handful of people who could realistically claim to be experts in C++ has gotten worse over time as the language has expanded though. It's a language where you potentially have to train new C++ programmers that join your team in how your team uses C++.

Well upto certain limits versatility is important. But, being too versatile also brings more complexity and it makes language confusing. I read more code than I write, so this versatily is not good for people like me.

Isn't the 'kitchen sink' approach what ended up causing Perl to fade from relevance? I am only casually aware of this, and I may be totally misremembering things, but Perl used to be seen as a swiss army chainsaw but people eventually came to realize that maintenance was a nightmare.

Perl faded away because there was an alternative (Python) and it was not a kitchen sink. For C++, there's no alternative at all. People have to bear with it.

I think Python's original take on kitchen sink was relatively small language with large "batteries included" standard library.

Ironically Python is now fast approaching the kitchen sink status.

From my webby perspective mod_php has been the Perl killer, and PHP isn’t known for being lean either.