> If someone was to decide to develop a game for a minimum performance requirement of a Pentium III at 500mhz and some GPU, for some reason (which would be a completely arbitrary choice, but that's the hobby, so roll with it) then the only way they can possibly check that out meets that minimum requirement is to test on a machine with that configuration.

This just doesn't happen in modern PC development, save for heavyweights who can afford multiple identical hardware configurations (e.g. HPC clusters). I know I'm repeating myself, but the variety of configurations just makes this highly implausible. Sure, you can be some demoscene type of guy who decides to target specifically this configuration, but then you're literally targeting one processor out of hundreds, and per your own words, the fact that it works on the 500Mhz doesn't mean it will work with the same performance on the next generation or even on the 550Mhz variant. I guess this is obviously fine, but really stretching it. You'll quickly end up having something that only works on your machine, with the same starting disk image, etc.

Even PCem doesn't fully simulate the x86 cache because there is no benefit to it, and that includes cores from eras which were much more sensitive to timing. Branch mispredictions? Forget about it. Most P3 software is going to run concurrently to some other software, anyway.

I'm not saying that you don't need a cycle-accurate simulator to get real timings. I'm saying that with such a large divergence in configurations and environments, virtualization (or any other inaccurate emulator) is likely to provide a performance level that is quite accurately somewhere in the interval. Most specially since you will have actually calibrated it to that interval beforehand :)

Now on consoles I can see the benefit. Consoles are lots of identical hardware, operating systems that tend to get out of the way, and the people who develop for them only test (for obvious reasons) on the console hardware itself or at most a developer edition which has the same hardware (for obvious reasons again). You can have a silent bug that depends on timing of a mispredicted branch or the relative speed between the bus accesses of two cores and _never_ notice it since your testing environment is exactly 1 device (such a bug would immediate flare on a PC on like the 2nd reboot).
Whatever it is that you develop for any one such console, it is highly likely it will work on all the million other sold consoles. Consoles are practically designed to have reproduce-able environments.

On the other hand you practically can emulate the entire x86 software catalog with emulators which _still_ have large differences in behavior at the actual instruction level compared to the hardware, so the instruction timing doesn't really seem important, and creating now some software that does depend on it seems .. complicated.

As an anecdote, not long ago I was working on a x86 emulator, and to my horror I realized that the push/pop instructions were actually miscomputing the operand size on a rather common but not primary situation (long mode but with a 32-bit segment). The emulator was pushing the stack by double the amount it should, and pushing/popping the high dword of registers it shouldn't have clobbered. This was actually happening in some of the most critical operating system code out there (bootloaders, WoW, etc.) ... and yet the bug had been in the emulator for years and no one had been the wiser, booting 64-bit OSes just fine :)