I agree that other ecosystems could learn a lot from the Node philosophy. And in general I enjoy working with the technology. But it's not all roses. In an ecosystem of small modules, you often find yourself wading through many -- equally small -- annoyances which can add up to a lot of friction. Here's a contrived fake example:
Your app needs ABCXYZ. So you go shopping for a module. The most popular one looks good, but when you Browserify it your bundle ends up with 1,000s of extra lines of code for the Buffer shim. So much for keeping that footprint small. So you keep looking and find another one that has a good footprint, but a weird API and it hasn't been updated by the maintainer since 2011. The next one you find looks great, but the maintainer decided they were tired of ES5 and didn't feel like adding a distfile, so you would have to install a bloated transpile toolchain to use it. You're getting annoyed but you keep going. The next one's author inexplicably decided to implement everything with streams. But you're too busy to spend a day grokking streams and reworking your entire API to be compatible. The next one is packaged as a jQuery plugin. The next one doesn't have a license. The next one uses Web Workers for no reason you can see. Etc. etc. etc. Repeat.
Any of these could be problems with a monolith (and monoliths certainly come with their own pile of frustrations), but monoliths are less likely to hit these problems simply because they consolidate effort and personal emotional investment around a certain set of techniques and standards, which leads to more consistency overall.