This isn't specific to Linode, but servers in general. If you were developing a large server infrastructure for an online game such as WoW or Eve Online that needs to be capable of serving several tens of thousands of people at once, if money were not an issue, would you choose to create a large server farm, each server only capable of supporting say 1000 people an one area. Or could you focus all of your resources into one huge system to be able to support say 50-100k people connected at one time in one area?

I would definitely distribute it as much as possible. Have a distributed service like that makes it much much easier to expand indefinitely by adding chunks of compute power at a time instead of having to worry about already existing infrastructure. I realize it's not quite what you were asking, but take League of Legends as an example. They have a few huge realms, but each game might run on a different server entirely.

Definitely as spread out as possible.

Your final architecture should ideally be able to suffer the complete unexpected failure of any node without any noticeable impact to players (other than perhaps a slight temporary lag), and minimally should be able to suffer the complete unexpected failure of any node with an impact to only a small portion of players served from that hardware. It should also support spinning up additional nodes on the fly as demand increases. That's trivial on the Linode side of things, but your application should be able to handle new nodes joining the cluster and sending load to them.

This is a nonsense question - money is ALWAYS an issue, so why waste time playing fantasy system design?

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

Well, money isn't really an issue in either case, because chances are 100 systems/nodes of capability n will cost roughly the same as 1 system/node of capability 100n... That's certainly the case at Linode for up to 40n, and probably also the case at larger cloud providers. That said, the single-big-node approach is counter to the whole point of cloud computing.

I'd imagine this would hold true in the colo space, to a point; eventually, the Xeon processors that support more sockets start costing a lot more.