At least for the optimization work I've done I've always had "real-world" test cases, and "drive the current bottleneck really hard" synthetic tests (I profile the real-world case, identify some bottlenecks, make tests that target those bottlenecks then optimize for that, then rinse and repeat), so I can understand why the various JS benchmark suites contain some very synthetic tests...
Except, unfortunately, they encourage people to keep optimizing that one issue even when it's long past being the bottleneck. Equally, what's a bottleneck in one implementation might not be in another.
Having the entire real-world case means you have to optimize for the actual case, and not just implement what was at one time the bottleneck in one implementation as quick as possible.
