In reading the question, and the answers, I'm kind of stunned by the vehemence of the NO case.
I've worked in software development for 25 years now, and I can say without any hesitation that programmers need a bunch of things to develop good code:
A REASONABLE development environment. Not dinosaur. Neither does it need to be bleeding edge. Good enough not to be frustrating.
A good specification (how much is done with NO written specification?)
Good and supportive management.
A sensible development schedule.
A good understanding of the users AND THE ENVIRONMENT the users will have.
Further, on this last point, developers need to be in the mindset of what the users will use. If the users have supercomputers and are doing atom-splitting simulations or something where performance costs a lot of money, and the calculations run for many hours, then thinking performance counts.
If the users have 286 steam powered laptops then developing and having developers do their development test on the latest 47 GHz Core i9000 is going to lead to some problems.
Those who say "give developers the best and TEST it" are partly right but this has a big MENTAL problem for the developers. They have no appreciation of the user experience until its too late - when testing fails.
When testing fails - architectures have been committed to, management have had promises made, lots of money has been spent, and then it turns into a disaster.
Developers need to think like, understand, and be in the zone of the user experience from day 1.
Those who cry "oh no it does not work like that" are talking out their whatsit. I've seen this happen, many times. The developers usual response is one of "well tell the CUSTOMERS to buy a better computer", which is effectively blaming the customer. Not good enough.
So this means that you have several problems:
Keep the devs happy and piss of the management, increase the chances of the project failing.
Use slower machines for development, with the risk of upsetting the devs, but keeping them focussed on what really matters.
Put 2 machines on the devs desk AND FORCE THEM TO TEST ON THE CLUNKER (which they wont do because it is beneath contempt.... but at least its very clear then if there are performance problems in test).
Remember batch systems and punch cards? People waited an hour or a day for turnaround. Stuff got done.
Remember old unix systems with 5 MHz processors? Things got done.
Techo-geeks love chasing the bleeding edge. This encourages tinkering, not thinking. Something I've had arguments about with more juniour developers over the years.... when I urge them to get fingers away from the keyboard and spend more time reading the code and thinking.
In development of code, there is no substitute for thinking.
In this case, my feeling is - figure out WHAT REALLY MATTERS. Success of the project? Is this a company making / killing exercise? If it is, you can't afford to fail. You can't afford to blow money on things that fail in test. Because test is too late in the development cycle, the impacts of failure are found too late.
[A bug found in test costs about 10x as much to fix as a bug found by a dev during development.
And a bug found in test costs about 100x as much to fix as that bug being designed out during the architectural design phase.]
If this is not a deal breaker, and you have time and money to burn, then use the bleeding edge development environment, and suffer the hell of test failures. Otherwise, find another way. Lower end h/w, or 2 machines on each desk.