The former is generally found in scientific computing (say, protein folding studies, or SETI@Home). In these kinds of problems, it's acceptable to have a widely distributed system with significant latency between nodes, because even though it takes you a long time to move the data across to another node, it's offset by the time you save in having another CPU perform work on it.
The latter is generally what you find in the business and web applications that are generating most of the heat in data centres today. These are things like stats aggregation, building search indicies, or plain old DB seeks. In these cases, it often doesn't make sense to distribute the work out over a connection with high latency, since by the time you've done that, performed a relatively cheap CPU operation on it, and sent it back down the wire, it would have been quicker just to queue it up locally and let the same node deal with when it had some CPU slots spare.
In other words the higher the latency between nodes, the less efficient the entire system becomes, and the less economical horizontal scaling becomes. In addition, there's a ton of extra overhead to maintain concurrency when latency is high.
It could be great for some niche problems though - like CDN, P2P relays, or local backup for nearby machines.