All of his arguments actually apply to all of javascript, and are not actually specific to node.js though.
These things aren't pain points in the browser the way they are in Node. I have never felt the need for an ORM in the browser. I have never dealt with client-side code that was using so many libraries I had to worry about whether exceptions would be handled via exceptions, or the first argument of the callback, or rejected promises. No one (at least, no one I know) is installing node modules like isArray to use in the browser.
Yes, these things _could_ technically apply to the browser, but it's not commonplace. In the node world, these are all things you deal with consistently.
Erm, well, considering the adoption rate of Browserify and Webpack, I'm going to disagree with you there. Especially considering React's momentum practically requiring some form of module builder.
Webpack doesn't bundle at runtime, it doesn't add any amount of code overhead per module that I can easily measure, and it doesn't trash startup speed.
It's something like tens of bytes (minified), FWIW, for the closure that each module gets put into.
Node has support for the built in isArray, and you only need that "micro module" if you want to support IE8