I looked at the actual code and, although I'm no expert with Node, it looks pretty reasonable. The only things I can find to criticize was the word "replacize", which makes me cringe much like "performancing" or "optimizely", and the use of == instead of ===. But I think reasonable people could disagree about those things. Someone who isn't me might think "replacize" is sufficiently humorous to retain, for example.
The nesting goes a little deeper than I would like: https://github.com/harthur/replace/blob/master/replace.js#L9... is 7 indents deep, for example, where I think something like 4 indents is a place where I should stop and start questioning what I'm doing. But three of those indents are a tradeoff forced by the node.js async API: anything that has to wait on the result of an asynchronous operation must necessarily be in another function, and you can choose whether to nest that function deeper or to move it somewhere unrelated and give it a name; and you have to use error codes instead of exceptions for error handling from those operations.
The program actually includes a synchronous version of the same code, where the line corresponding to line 90 above is https://github.com/harthur/replace/blob/master/replace.js#L1..., the blank line following "var text = fs.readFileSync(file, "utf-8");". If that fails, it throws an exception, so the "if" block isn't needed, and the code that follows doesn't need to be nested.
This is the agony and the ecstasy of Node: everything is (normally) asynchronous, giving you unwanted levels of nesting, but on the other hand, everything is asynchronous, so you can process the files in the order that the filesystem finds it most convenient to return them to you in. I wouldn't be surprised if it turned out that Heather's code was typically much, much faster than find | xargs -P sed, simply because it was able to productively manage many more outstanding I/O requests at once.
Line 90 also points to a pitfall that often befalls us with parallelism: at some point parallelism stops being productive, so you have to limit it. In this case, Heather's code throws the ball back to the user and suggests that they rerun their command in synchronous mode — albeit having partially completed the replacement task, which might be a bad failure mode, depending on whether your replacement is idempotent.