I'm not sure how #4 is weird. It can make sense in certain circumstances, as template rendering can be quite expensive. Making this change, though, without data from profiling is probably unnecessary.
Although you didn't touch on #6, they probably should have explained this in a little more detail.
It does sound like they made the decision to use binary modules as a result of profiling, and the fact binary modules exist might be useful info to a node n00b.
This article should probably have been presented more as food for thought, rather than Node's pseudo ten commandments for performance, but nevertheless, it's a useful article for the most part. Developers (well, seasoned ones at least) know to apply critical thinking to all advice anyway.
My remark was against their "Keep your code small and light". Making your code lighter doesn't always make it faster. If you can get your code to do less (like, skipping memory-based sessions), that will make it faster. If all you're doing is avoiding complexity, there's no guarantee it will be perform better.
The proper way is to benchmark and profile. You can refactor your code based on developer happiness, but only try increase its performance based on objective data.
EDIT: I should probably clarify this (although it seems silly to have to do this on HN): I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.
If you are in a different environment, the arguments for/against become much different.
Node doesn't really give you much of a choice. If something is going to take awhile then you will be using callbacks, it's that simple.
2 is just a bad tip. Socket pooling is a useful feature. Opening up more connections than you (or the server) can handle will lead to poor performance.
3 and 5 isn't Node.js-specific and you're better off reading https://developers.google.com/speed/ to learn the fine details.
Instead of following 1, 8 and 9 you should learn how to profile your application so you can find the true bottlenecks of your app.
4 and 7 are just weird. Going session-free or switching to client-side architecture are both big tasks; I'd love to hear more about the real challenges, not just "this is fast, zomg!!"
I wish this post had more meat. How did they end up with these tips? How did they profile? How did they benchmark? Where can I read more about the other tips? Without any good links to learn more about the details (seriously, linking to gzip.org was the best you could do?) I'd say these tips can almost do more harm than good…