Initially, the choice was made because of their mailing list, which was filled with testing professionals and had a good gender ratio representation. So active community of testing professionals who were adopting Node and could answer questions. Really great API documentation, too.
It was a slog to get the integration working at first. Where to put config files, get all the different pieces working together, adapt to Meteor’s reactive architecture. But that’s all been mostly worked out and documented nowadays. It’s been a workhorse ever since.
Their config file is brilliant, and all the options have allowed us to have testing-fu whenever the runtime environment changes. Node upgrade? Meteor installed in a different spot? Package only architecture? Headless API server? Running on CI server instead of localhost? Just update the config file, and keep going.
In my opinion, it’s very much a situation where things that are easy to set up are sometimes difficult to maintain; but those that are difficult to setup are easy to maintain.