These are different levels of CPU-bound-ness. Comparing for-loops (which barely cost anything) to encoding video or computing PI for example is not comparing apples to apples. The body of a for-loop will typically greatly dwarf any "overhead" incurred by the for-loop construct itself. Obviously any non-I/O tasks like these are going to be CPU-bound. What I meant was Node is good at waiting for databases, web servers, file systems, etc. to respond to requests without blocking other work.

>Most services in the real world soon get closer to Mandlebrot As A Service than "pure I/O".

I disagree with this. I think most web apps spend most of their time waiting on the network, file systems, etc. to respond.

>What about the reduced cognitive overhead of not having to deal with JS on the server though?

I don't understand this question. JS is not a hard language to learn/pick up and there is a large number of developers out there who already know the language from working in the browser. However, my main point there was about using a single language. Yes, technically you can use Ruby, PHP, etc. in a browser (via JS), but nobody does that because it'd be very slow compared to just using JS from the get-go.

>Plus, aren't usually the backend and frontend teams different ?

It depends. I would say for most small businesses (and including the many "one man team" developers who do remote contract work for example) this is not the case. I cannot speak for large corporations, but there is definitely a larger possibility of having separate teams there. However just because you have separate backend and frontend teams doesn't mean having separate languages on each is any more beneficial (e.g. code sharing in some cases can be a win when using the same language). There's also the benefit of being able to "reuse" a JS developer on either end, depending on the work that's needed.