tl;dr: It's all about cost, about how do you decide to assume risks and how you approach evaluating costs.

I do agree with this one thing

npmgate had nothing to do with the size of the left-pad module

But not with the rest of the argument. What this whole affair (really? are people calling it "npmgate"? meh) is about is two things: one, cost; two, professional behaviour. But mainly, cost. Everything is about cost.

Note: Do not confuse cost with money. Not everything is about money, but everything is about cost.

The problem, the real underlying problem is that we evaluate cost in a too casual fashion. In this case, some people saw a left-pad module existed and didn't go any further. They didn't consciously ask themselves: "Ok, what is the cost of using that module?" At most they just went with the simple reasoning of "someone has already done this, this is solved" and assumed there would be no cost expect for doing npm install --save left-pad and that's it.

In the end it turned out that there were indeed other costs they hadn't thought about. The obvious one: It makes you depend on an external circumstance (or more than one). And maybe, some people did think about this, but decided that this was affordable, that they could assume the chance of a potential future cost appearing in exchange for "no cost now". If you actually thought about this and assumed that possibility, then I expect you just saw the problem and understood what it was and did not complain on the web. If you didn't think about this and you complained, I'm sorry, you should have thought about it.

Now, there is, of course, an additional difficulty here at play: micro-modules and NPM generally both amplify and hide the problem of external dependency. In the sense that you may want to decide to depend on a certain module or tool, but then you're depending on that module or tool's dependencies and the dependencies of those dependencies and so on. Which, if you were to investigate, sure, would make the cost of evaluating a module or tool quickly rise.

It generally ends up being a balance. The cost of evaluating, the cost of developing, the cost of dependency. You end up tending to favour one or the other and behave accordingly.

My opinion on "the defence of micro-modules" (not on the micro-modules themselves) is that the people defending are favouring the cost of developing at the expense of ignoring other costs. In particular, I think they pretend that people should adopt a too careless approach at the idea of evaluating. The simple approach of "oh, it has N stars and M downloads" is not always enough. And the simpler one of "oh, I found it on NPM" is downright irresponsible in a professional environment (it may not be in a private circumstance, that's your call).

They also seem to favour thinking about the cost of developing in a very particular way. They seem to defend a thinking like "writing even one line is too much if someone else has already written it". This is, of course, a matter of opinion. My opinion is that this view is too extreme and one, twelve, even too hundred external lines may sometimes not justify at all the potential cost. They may, but they may not. That is, my opinion is that one should decide on a case by case basis.

In particular, I wonder how many people actually went and read carefully the left-pad code. How many actually thought about it. left-pad does some dubious things. I'm not saying wrong, but things that should make you pause and consider the quality of the code. Because, of course, the cost of an external dependency also varies a lot with the quality of that dependency.