Short answer: No, I don't think that timings of implementations are necessary for a good performance review of an implementation, I think it makes the most sense to let the OP perform their measurements. And for algorithms, an answer should talk about their big-O time complexity, but not specific timings.
Long answer: Timing of specific code depends on way too many variables, you mentioned some of them, others include compiler (and its options), the data used for testing (their size, but possibly also their “shape”), and how does the piece of code under review fit into the whole program (does it just call the code over and over, or does it also do other things? this can matter especially in multi-threaded programs).
Performing good timings may also be relatively hard (you need to produce the test data, the OP almost never gives those) and time consuming.
So, I think that producing timings would take too much time and effort for the answerer (reviews can already take quite some time, we don't want to make them even more time-consuming) and they might not be very useful to the OP.
As for algorithms, their timing would provide even less useful information (because an algorithm can be implemented in different way, with different performance characteristics). But there is a better option to compare performance of algorithms: determining their time (and possibly also memory) complexity, using the big-O notation.
Time complexity of an algorithm is (usually) much easier to figure out and it doesn't depend on any of the variables timing does, so it doesn't suffer any of the problems mentioned above.