My overall sense is that there's been a pull back from general benchmarking compared to say, 15 years ago, and it's unfortunate, because it leaves the benchmarking to developers of languages, compilers, and whatnot. This provides an opportunity to show of the best-case scenarios for the languages, but also for them to hide the areas of weakness -- and those hidden areas are often the mine traps for those deciding whether to invest resources in a new language.
Having a standard, comprehensive set of problems helps address this "hiding." I also think there's value in naive benchmark programs as well as "expert" tuned ones: not everyone is going to optimize every single scenario in every language.
The one thing I've never seen implemented well is some measure of "ergonomics" or "high-level" versus "low-level" aspects of a language, which also seems important to me. Some of that is going to be subjective but some of it not.
It always comes from one direction: engineering.
Benchmarks have multiple audiences and multiple uses. What servers one customer (perhaps a microarchitect tuning a pipeline) does not serve another (a company building a product that has to choose a particular component) nor another (a professor looking at historical trends).
Of course if you try to turn a screw with a hammer it's not going to work, so choose the right benchmark for your analysis.