The problem
This little rant was provoked by this article by David / Haney. While I agree with much of what he says there, I do not think that developers should "write their own bloody basic programming functions" like left-pad. Or rather, they should not have to.
Yes, bundling or implementing the left-pad function in your own code would have prevented the removal of left-pad from the NPM repositories from breaking your project.
However, forcing each project that needs to left-pad some value somewhere to implement, test and maintain the left-pad code is a waste of precious human time and brain power. Also, the 11-line left-pad everyone is currently making fun of may be trivial, but such things can quickly stop being so trivial once a few special cases creep up, and before you know it, you end up with a balkanized ecosystem where left-pad means a slightly different thing in every project you look at.
On the other hand, it is obviously true that the higher the number of your dependencies, the more likely it is that you will run into problems like version conflicts or upstream authors breaking your stuff.
Looking at the root cause
What was the real problem with the packages depending on left-pad? In my opnion, there were two root problems:
Projects not being fully aware of what (and whom) they depend on.
Which third-party services does your build / delivery pipeline / development environment depend on? If you cannot answer this question immediately, you have a problem. This is especially true for centralized services, and it is one of the reasons why I am a little critical of Github and its satellites like Travis.
If it is important that your build is reliable, run a local NPM / PyPI / whatever mirror. I am of course guilty of not doing this, as is half of the "software industry", apparently. However, if you don't do it, don't complain ;)
The fact that Javascript lacks a decent standard library.
The (historical?) need to abstract away differences between browsers is not the only reason that there are a myriad of frameworks that more or less try to implement a programming language for DOM-manipulation on top of JS. jQuery is probably the most popular one, but there is no clear de-facto standard that everyone agrees on and collaborates on to improve it.
Even though JS' focus clearly is the web, it lacks built-in support for obvious things like building URLs. Blaming developers because they depend on third-party solutions for these common problems is the wrong answer. The right answer is to provide a good standard library.
About micro-packages
Is it wrong to create a package with a single tiny function like left-pad? Yes. But the answer is not "don't package it". The answer is "package commonly needed stuff into reasonably-sized packages that group related functionality together". A package just for sin is probably stupid. A package trigonometry is better. Having a math package is probably a good idea.