Swol is more of the healer guy for us, but I have written a lot of code over the last 10 years for running simulations, calculating stat weights, optimizing, etc., and I can tell you that this isn’t always true. There are specs where a pretty uneven distribution of stats performs significantly better.
You can do a simple example to see how even the slightest shift in the relative value of your 4 secondary stats would make this untrue.
With a given budget, say you could get 20% crit, 20% haste, 20% mastery, and 20% versatility. And to make this somewhat realistic, we’ll say you have at least 5% base crit and 8% base mastery, so your actual values for those will be 25% and 28%. This gives you a multiplier of:
1.25 * 1.2 * 1.28 * 1.2 = 2.304
Now let’s say you redistribute your stats and dump all your haste, spread it equally over the other three stats. Your multiplier would become:
1.31667 * 1.34667 * 1.2667 = 2.246
The difference here is pretty small – you’re talking ~2.5% output difference. We ignored a lot of nuance, but this gives you the right ballpark, enough to see that even small imbalances in stat value might make completely ignoring a given stat optimal.
Calculating based on a log of player activity is actually pretty difficult and presents many challenges, though it would be cool. The first challenge is getting enough aggregate data that is sufficiently similar with which to calculate. Basing it on a single log isn’t that useful… there is too much variation from fight to fight. And most groups don’t do enough trials under similar enough conditions to make aggregating easy.
The second challenge is that each fight, and even each phase of a fight, can be pretty unique. It’s probable that a user would not want to optimize for the whole fight but only for parts of it. This becomes a difficult user interface problem, and also a set of difficult choices for most users. It starts to slip into that category we try to avoid, where a person needs to know the answer in order to use the tool that gets the answer!
Thirdly, the log-based approach runs into a huge confirmation bias problem. You’re only going to find enough data with logs that have popular stats builds, which will influence how people play, which will influence your results. It will be difficult to find alternative ways to play. This is not to say it would be impossible… just very hard. Related, the way people play is going to be based around the popular builds… which may not be the proper way to play with a completely different set of stats. It is difficult to extrapolate from logs of everyone playing high haste builds to how well a low haste build would perform.
Something abstract like a simulator is better for exploring more theoretical possibilities. A calculation model is even better in my opinion, since it is faster and even less influenced by the current meta – writing rotations for simulators is very difficult and will usually only be optimized for the more popular approaches. A calculation model can be written in a more objective manner and changed much more quickly as the game evolves.