Its evident from the flamegraph that the architecture is fundamentally different. Why are the stacks so deep in the javascript example? Why aren't they using a similar worker pool in the node implementation? Are they just throwing everything onto the event queue and treating that as a naive worker pool?

If you know the limitations of your tools then you can work around them. This was clearly not done in this case.

I would like to know more about the implementation.

I have had node do 12000 requests a minute with no problem (on a single core). In this case they had 4 two core boxes, so they needed each one to at least perform 42 requests a second under max load.

I want to know more :)

Doesn't really make me wonder. I haven't really seen anything about python's new async stuff that indicates it's on par with node's (reply here if you found anything, I've been looking for this information!). And if python is caught up with node, it would be at very high risk of performing the same and having another random performance gotcha. Golang is one of the natural choices to replace a nodejs application for performance reasons. It's low-level, faster, uses less memory.

Care to explain why python async would have performed better? I don't see a single way in which python async would be a better alternative for the given job. I'm a python guy myself but, when it comes to async stuff, I find nodejs much better and easier to understand/follow through (even with cb madness yes). For the described job, I would have went with Elixir or Go as well yes.