Most web applications are io bound not cpu bound as they spend most of their time talking to other systems across the network like your db or queue or some rest service. the cost of spinning up threads is memory and context switches by the os. Async is just a way to avoid this for io operations. Node.js is just an incredibly convenient way of doing this as there are less ways of shooting yourself in the foot than if you apply the async patterns to other tech platforms.

Cpu bound is still cpu bound on any tech platform and needs another strategy to deal with it. I think it's better to look at node.js as a tool in your toolbox that is well adapted to running high load web-services and apps that are io bound instead of a swiss army-knife that does everything great.

But as any toolbox you need more tools in the box to be a good carpenter. That includes picking tech that can do the cpu bound stuff in a appropriate manner, be it java, scala, c++, erlang whatever. You don't write a graph database in node.js unless you are masochistic. Just as you hopefully don't write an async server in assembly.

From my usage perspective node.js is great for my async needs and the low resource usage means I need less hardware to scale my typical web app.

True, but wouldn't just making IO async be enough?

Yes it would and in fact most language platforms have async io. It's just harder to keep your yourself from introducing blocking calls in your event loop as they come with mostly blocking libs :)

Well, there is plenty of point avoiding blocking on IO if blocking on IO is your bottleneck, and blocking on CPU is not. For some reason, a lot of people have focused on that case for many years.