It's not so easy to just "choose the right package". Often all the packages for a given function are someone's hobby.
Consequently JavaScript code needs constant, expensive maintenance. Whereas Python code can rely more on the standard library and big frameworks and tends to keep working for years.
Programming language designers should see themselves as builders and curators of great standard libraries, the language itself is almost incidental to that goal.
In terms of value proposition, I think the author is just hankering for some .NET style support agreements in order to hedge his maintenance cost bets - and I'm sure there are or will be plenty of consultancies willing to provide this service, so long as the demand exists. That open source language users are entitled enough to expect this service for free from language maintainers... I'm not sure that's completely justifiable.
I don't see the standard library and third-party packages as being in opposition. Far from it. A rich standard library encourages a rich ecosystem of third-party packages.
Maintenance costs affect the authors of open source packages even more than they affect commercial users. They are working for free and in their spare time. A rich standard library makes a language attractive to people who want to write packages.
I don't think you even need to just pick one crate for a particular functionality - narrowing the field down from 23 to a handful with well-understood strengths and drawbacks would be a good start.
Python is actually a good example of this. Look at the library ecosystem built up around scientific computing. None of that is in the standard library, yet there is a common set of packages being used.
C++ takes the approach mentioned of having a rich standard library (Boost) that is a separate project from the core language. It (IMO) does not work very well. Many C++ programmers don't use Boost and generic C++ libraries are unable to use Boost as a dependency.
That is because a boost installation litters your hard drive with several hundred thousand tiny files. I can't in good conscience require end-users to install that monster to compile my 10Kloc project.
As a result many libraries are close to de facto standards because any Java dev can easily get those libraries, regardless of being on Win, Mac, random Linux distributions, etc.
Node.js is popular, but it's not 'standard'. It's not part of any ECMAScript standard libraries, which would be the requirement if it was to be standard.
I don't know the situation with Go that well, so if it has a http library in the standard I'll take your word for it, but there do seem to be some popular non-standard http servers like Caddy.
As for Python, this is probably an example of where the impact of standards is not that great. How often is the standard http server used compared to popular third party alternatives? Are there any web apps you know of that are using the standard http server in production?
Perl users brags about the numbers of packages in CPAN. For me, that's a nightmare. There are a dozen packages for everything. Each time I pick up one (more or less at random after wondering for hours which one I should pick between all those, which are irregularly accurately described), I discover a few weeks later that there are bugs in this package, or that it is deprecated, or that it has been reimplemented for better performance with a slightly different name, or that the procedural access to the features disappeared in next version, or that the package Y version 0.12.3 is more stable than the package X version 2.1 that I chose, or that oh in fact this package function is TODO so I have to switch to another package because it's been marked TODO for 13 years, or that I have to ditch the package I use when my program grows because it does have the extra features I now need and I should have picked up another one from the start, etc.
So I try as much as possible to stay away from packages which are not in Core. The problem now is that even those 'standard' modules are in fact not so standard for Perl distributions which may omit some of them...
And then you have to fight between the packages provided by your OS/Perl distribution and the ones provided by CPAN...
I sometimes end up rewriting everything in C, where there is one standard library, and then de facto standard/widespread libraries with not many alternatives, so it's hard to pick a wrong one.
-------
Same problems for CTAN (Latex). Plenty of packages but most of them are incompatible with some others. In the end you may not be able to use them if you happen to need the 'wrong' combination of features.
For instance basically nothing comes in the standard library for C. If basically nothing is offered in the standard library of Rust then why switch? It's valid point.
If we want a lot of adoption to Rust, people need to have an easy way to find quality implementations in crates or add them to the standard library so they are easy to find. Either way, you need one of those two things to happen because people are lazy.
Languages are a lot more than the standard library.