I read it as -- "Node.js doesn't properly support isolated units of concurrency and thus due to being forced to write callbacks inside callbacks that call errbacks for everything, we now have over 50k modules full of callback chains and we call this a GoodThing(tm)".
In the java ecosystem, most of it assumes blocking IO. If you're trying to get out of this mindset, the ecosystem can get in your way -- or at the very least, it's not making your life easier.
For many things, this is fine. If I'm not twitter, I'm trading increased scalability for readability almost every time.
For projects that just need occasional async, I would prefer the grails 2.3 model -- http://grails.org/doc/2.3.0.M1/guide/async.html -- which will get you 95% of the way there in a more readable way. ___
However, I am a bit more charitable toward node. I think this may be a case where there is enough momentum that, as people start hitting the harder problems, engineering solutions will sprout up, and the platform will mature with better patterns turning up (including generators and promises.)
For example Python's eventlet and gevent are based on greenlet. Greenlet is based underneath on large select/epoll/kqueue/poll loop. So there are callbacks for IO readiness there. However they manage to do some tricks to hide that away behind green threads at the user level. So a user can say: " authorize() ; check_database(); charge_credit_card(); update_database(); send_response()" logic properly for each request for example. Without having to split that logic into a chain of callbacks just because some of them might involve at some point making a socket call.