Zakas' post isn't really about the crusade for Node.js. At least it shouldn't be anyway. It's about how he perceives a change in UI architecture. I think it's a bit weird that he specifically uses Node.js as you can accomplish this with any "back-end" server language/framework. I think he does a poor job of communicating the change as well. It really boils down to one thing: Some people are generating templates client-side instead of generating HTML sever-side and sending it down. What he refers to as the "Back-end UI layer" is simply just a server generating HTML.
I can't really argue whether his approach is good or not. The way he explains it seems like an extra useless layer that you're going to have to maintain to me though. So you have a RESTful PHP/whatever app returning JSON or the like. And then you have your front-end developers create a Node.js app that takes the PHP apps response and ends up rendering HTML or just returning that same JSON anyway?
I agree that business logic and rendering that business logic into HTML, JSON, whatever are separate concerns but there's no reason why you can't implement them in the same language and just give the client (browser, mobile, whatever) what it wants.
I think there is value here. The way I see it: there are sometimes calculations that you want to perform on the server, but that are logically part of the UI layer. Maybe you need to aggregate the results of several service calls for a particular screen. Maybe you need to do an operation that's actually several steps.
You could do this all on the client side, of course, but that would perform badly, and might make e.g. security more complex. You could do it on the backend, but that results in a backend service that's tightly coupled to the UI - bad architecture, and possibly requiring close collaboration between two separated teams. By having a component that runs on the server, but belongs to the UI team (and therefore necessarily needs to be written in a language they understand), you get the best of both worlds.
It makes a lot of sense. With services architecture the backend team shouldn't be concerned with the web client but because of historical reasons this is typically how things work.
See, I think the fix not using evented programming with tangled callbacks but spawning a (green) thread. Just because PHP does that model inefficiently, shouldn't be a signal to dive into evented programming but find something that does that model right.
Some example: Python's gevent or eventlet based servers. Java's vert.x server. Go, Erlang, Rust. All support a more sane model I think.
For instance, if you need to run 3 SQL queries in PHP, then the total execution time will be t1 + t2 + t3. On the other hand, if you make those queries in NodeJS instead, it will be MAX(t1, t2, t3).
So, it depends on the complexity of your app and your ability to decouple and separate concerns in the NodeJS server.
If node is being used simply as a proxy then—no question—throwing it in to the mix will simply introduce latency (shortest distance blah blah blah). However the suggesting made by both the article and EGreg seems to be, "use the right tool for the job." In the case of the article, Nicholas seems to be suggesting that aspects of your data model might be better suited in the hands of your front-end engineers as they're the ones presenting that data. EGreg is suggesting leveraging the asynchronous nature of node (and evented programming in general) to handle certain tasks more efficiently.
But to answer your question, not necessarily. Even if you introduce additional latency, you might still benefit from putting more of the data model into the hands of your front-end guys (particularly if you're at a massive organization where coordination is the biggest hurdle). Plus, there's nothing stating you can't push the mutations performed at the node layer down farther into your stack and, potentially, remove it entirely. And, there's also the case that node might do the work you've delegated to it more quickly than if it were performed in PHP, negating the loss due to additional latency (but if that additional latency is the concern, I'd recommend relying benchmarking to help you make that decision).
If Node.js can do things like
* cache responses
* not send duplicate responses but instead maintain a waiting queue
* throttle requests based on # of preforked threads etc.
then it would be faster most of the time.
And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.
Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc.
Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting.
etc.
It can work, though you lose a bit of transparency.
Consider this: you have a site that will have to scale to millions of people. If you have a lot of reads, you can simply replicate your database, but if you have a lot of writes too, then you'll need to shard (partition horizontally) your database.
An aside -- if you find yourself using an ORM and sharding a lot, then most likely you should have used a NoSQL database such as Riak, instead of a relational DB. But let's say you've already gone this route, and used MySQL, which a lot of sites including facebook have done.
In this case, anytime you need your query to hit N shards, PHP will take (s1 + s2 + ... + s_n) time to do it. Node.js will take MAX(s1, s2, ... s_n) which is much faster. There is a big difference for latency. (It's true that the mysqli driver in PHP does support concurrent queries, but the above comparison isn't just for DB but for EVERYTHING. In JS and Go you have the option to do concurrent I/O, in PHP you don't.)
Another difference is in the memory usage. PHP has to create a copy of your environment for every preforked process. It depends on Linux to do copy-on-write, for instance. APC helps a little with shared memory segments, but not much. On a 2GB RAM machine, how many clients can you support with PHP vs Node? Node has just one copy of the code running, and each request costs very little in comparison. Of course, since everything is in the same memory space, you can easily bring down the whole process, so Node.js processes need to be built to survive crashes, unlike PHP scripts which are isolated.
And let's not forget that Node.js stuff can push to the client, whereas for PHP to do that you need wasteful, long-running sleeping processes sitting in memory, and having some nginx event module to simulate evented programming.
In short, Node.js and stuff like that gives you much more flexibility, many more things you can do (such as pushing data in near real time to many different endpoints including the browser), but at the same time you need to code everything in a way that crashes don't matter much.