The most helpful resource I've found about v8 specific performance is the bluebird optimization killers wiki: https://github.com/petkaantonov/bluebird/wiki/Optimization-k... wiki, and the v8 bailout reasons repo: https://github.com/vhf/v8-bailout-reasons
Write readable, natural code, and compilers are more likely to eventually optimize it, even if perhaps they do a bad job today. Only contort your code to improve performance if you have profiles showing that you need to do so, and even then, see if there's natural code that works first.
The asterisk comes from the costs of having multiple shapes for a given variable. V8 (to my recollection, it could very well be out of date) generally has a performance cliff between monomorphic and polymorphic functions: if the added strictures of typechecking is giving you monomorphic functions, it could see a performance improvement. Other JITs (again, to my recollection) are generally happier to have polymorphic functions where the degree of divergence is still small (say, two or three shapes), although having 1000 shapes is going to be unhappy for everybody.
Note that this discussion is effectively microoptimization-level discussion: don't rearchitect your code to enforce monomorphism at the expense of clarity unless you have profiling evidence that the performance is necessary.
You are correct that these no longer apply to the most recent Node versions. Crankshaft is still being used in Node <8.3.0.
Crankshaft got totally disabled starting from V8 5.9. Node 8.2.1 uses V8 5.8.283.41, Node 8.3.0 uses V8 6.0.286.52.
I'm pretty sure there is still a big number of projects running on Node <= 8.3.0.
I'll make it clear in this project README though, whenever I find time. :)