There is no one correct answer and the popular opinion on this swings back and forth constantly. My personal view takes into consideration what happens when a server dies. For everything I've ever worked with multiple smaller servers make recovery simpler. In a pinch I could use a workstation to fill the void while waiting for a replacement server to arrive. Others have their own reasons for favouring fewer and more powerful servers, with virtualization being a common(try replacing that one with a workstation!). The truth is, neither answer is going to apply everywhere.
The best thing you can do is having a server for MySQL only and one for PHP+Memcached. Then, depending on the load you put on these, you can load balance them with some more server... The database server should always be the most powerful as is must serve many request at the same time.
That said, I must remember you that it always depend on the load websites on these server generate... For a small site, let's say 4000 visitors a day, you can easily put everything on the same server, but if you're talking of a website with more then let's say 10k visitors per day, then you gonna have a major advantage by splitting your service (mysql, apache, etc) on more then one server. It's also very depending of what kind of website you're talking about.
Hope this help you a bit.
Everything you need to know about Scaling Up (Big Iron servers) or Scaling Out (Lots of little servers) can be read on Jeff Atwood's post here: http://www.codinghorror.com/blog/archives/001279.html. Follow the links in his post to "My Scaling Hero", which also gives you a good story.
There are no answers in those posts, but it will give you clear direction on how to reach your own answers, because everyone's answers will be different.
And if you've no idea who Jeff Atwood is, he's one of the founding fathers of the Stack Overflow/Server Fault/Super User sites, and a world renowned blogger in the programming/IT field, and whilst you should never take any personal opinions on the intertubes as gospel, the hard numbers in that post really do provoke some thought.
The dilemna is always the same : "Many servers" cost less, but they are generally less stable : so the maintenance time increases. (I know THAT IS NOT something always true...)
"Few servers" costs more, but there are generally more stable (due to the high quality components) BUT that also means that you will host more services, if you have any issue, more services will be impacted.
you should consider the virtualization, it combines the both questions : you'll have a high quality - rox stable server and inside your "many servers" If there is any issue, only the concerned server will be impacted.
From what i've experienced (small experience thouhg :p ) it's always better to put the price in order to avoid pains later. In production, people don't care about our issues, they only want to see the thing working at anytime
Probably some questions that if you can answer will help you...
A few big servers:
Can you get a server big enough? Does your load scale out on this server? What happens when it fails? Can you buy two of them or pay company XXX enough to fix it fast enough?
Many small servers:
Does you load scale out with this model? Some loads do, some don't. What happens when one fails? Can the remaining N-1 deal with the load until you fix the broken one? How fast can you get a new copy of the server you need?
If you go with the many small server model, I would go for configuring them as close as possible so that you can substitute one for another.
We use puppet for this so that servers can be swapped, and, renamed, and volia, the system is up. Well, the new system is up modulo the debugging that you have to do because you forgot something..