A language's surroundings can still be improved, the documentation can still be improved, new tools can still be made, new libraries can still be written, etc.
And at the end if the language is inadequate for something then simply use something else that fits better, there is no reason to force all languages be gigantic kitchensinks.
On the other hand, it is a lot of work to build your product in one language, which you then outgrow, which forces you to switch to another language.
I've seen this happen many times, particularly with projects that started out in Python. Eventually the codebase and teams get too big, and managing a large codebase in a language with Python's type system becomes very cumbersome. Type annotations were a reaction to that, and adding them to the language has probably enabled a lot of teams to continue using Python.
Off the top of my head, other examples of good changes include NIO and better concurrency primitives/lambda syntax in Java, generics in Go, and async/await in several other languages. All of those solved pain points for developers that might have otherwise been solved by switching languages.
Why does this matter? First of all, it's a lot of work to rewrite products in different languages. Also, while it sounds attractive to pick the right language for the task every time, in practice it is difficult to run a coherent engineering organization if every product or team uses a different language -- it's hard to build good shared libraries and app frameworks for every language in use, and if someone leaves the company it can be hard to transfer their projects to other engineers. Most of the time, as an engineering org matures it eventually settles on a few "blessed" languages, invests in good frameworks for them, and requires all the teams to use them. Out of necessity, those tend to be the "kitchen sink" variety.
This is about why you may want a kitchensink language, which can be fine depending on the case and a criterion for choosing it as "the right language" (or skipping a language) for your case but it isn't really about making all languages kitchensink languages. The comment above implied that languages which'd try to avoid becoming kitchensink languages would be dying languages - as if these are the only outcomes.
And at the end if the language is inadequate for something then simply use something else that fits better, there is no reason to force all languages be gigantic kitchensinks.