The main article wasn't particularly insightful. Obviously, remote calls are expensive. Wow, that's news.

The use of separate physical layers has its place (he even mentions one). Use it where it makes sense, and don't use it where it doesn't. Of course, that tends to be easier said than done, as everyone has their own opinion of when and where.

Unfortunately, whether something is "good" or "bad" in IT seems to resolve too much around "performance," whether that's via scalability (which is certainly important), throughput, latency, etc. Those are aspects of a system, but are not (necessarily) the most important (that's where the requirements come in).

Some of the places where I think physical layers work (and not necessarily because of scalability, performance, or whatever):

--Like he mentioned, the movement of static content into the web server is a definite performance gain (this is mostly because of the way the app servers are written and the use of memory, etc.). Unfortunately, in the J2EE world, this is a lost cause (to a certain extent), as the static content is usually bundled up with the web application, itself (it would be cool to see an app server/web server combo that was able to dynamically pull the static content out and stuff it onto the web server, but I digress).
--Failover ('nuf said).
--Organization (whether via politics, multiple clients types, etc.)
--Budget issues (better cost utilization of hardware, via putting low processing stuff on cheaper boxes)
--Security (firewalls, etc.)
--Special circumstances (based upon special requirements, etc.)

There are probably other reasons I couldn't think of off the top of my head, but that should prove sufficient.

Dan