Not only is the shop in business, it's one of the most profitable place I've had the pleasure of working at. The policy was actually handed down by the CTO, who started in the company as an entry level developer. Some money was incidentally saved, but, at least to hear him talk about it, it was more about getting people's incentive structures in line: If you want to discourage developers from doing something, the most straightforward way is to make it painful for them to do it. If you want to make creating performance problems painful, you accomplish that much more effectively by making it apparent on their workstations, where their nose will be rubbed in it constantly until they do something about it. Slow performance on an external test environment is much easier to ignore, because people typically don't bother testing there until they think they're basically done with their work, at which point their incentive structures are nudging them toward ignoring any potential problems.

Contrary to some of the criticism I'm seeing here, it wasn't actually hated by the development team, either. The hypothetical "can't get any work done because compiling takes a bazillionty days" scenarios that people are pulling out of thin air here simply didn't happen. At a shop where developers were expected to think carefully about performance and know how to achieve it, they tended to do exactly that.

Someone who was busy making excuses about how they weren't very productive because they only got a 3.4 GHz CPU while the analysts got a 3.6 GHz CPU probably wouldn't have lasted long there.