Once things are in the standard library, they're basically impossible to remove, unless you want to break everyone's code and prevent them from updating.
If you're making a new programming language today, the standard library is a place where you should think very carefully about everything you add. Every programmer learning the language will have to be familiar with the standard library, so keeping it small is good. But too small, and programmers will always have to reach for third-party packages without maintenance or stability guarantees. For example, you don't want to have to choose among 5 different libraries to write and run unit tests; the language should define that and it should meet everyone's needs (or be extensible with a small third-party library).
I think the Rubys and the Perls of the world probably choose too much to add to the standard library, and that's where the comment you're replying to comes from. But, while it's easy to overdo the standard library, it's also bad if you underdo the standard library. Tough and sometimes under-considered aspect of language design.
Depends also on what you mean by the "Standard Library".
Back in the day Ruby had built in language features (e.g. Innumerable), and a standard library that was bundled into the distribution (e.g. GServer).
More recent versions of ruby have significantly streamlined the standard library, pushing a lot of the functionality into Gems (libraries). Given that the use of a Gemfile to list library dependencies is absolutely standard practice, the upgrade path simply involves adding a line to the Gemfile.
In practice, these changes have been very well signposted before they have happened.
This is a very good point. Things done wrong in the standard library are often done wrong permanently and forever. Particularly given the current demands from some people for perfect backwards compatibility.
Looking at the stdlib for a language like Rust it tends to feel like people who had 20+ years of experience in other languages went and thought deeply about the problem, with an understanding that accepting the design might be permanent.
Not the parent, but my usual response to this is always "well someone's going to use it in the codebase, which means I'm going to have to end up using it too".
