I don't mean this answer to criticize your question in any way because it's actually a great question. My opinion, however, is that this is sort of the wrong question.
I think a much easier and more relevant test is not how fast some calculation is on, say, a single core, but how well the implementation scales across many nodes, each with many cores. This is because many people doing quantum chemistry have access to very large computing clusters (either through their university, national lab, company, the cloud, etc.). Despite this, many electronic structure packages do not scale well beyond even a few nodes. Sometimes this is because the method does not scale well, in which case the code cannot be blamed, and sometimes it is because the code was not written to scale well. Usually, this is because the code was originally written in like 1970.
I hesitate to be too specific because I have not used every electronic structure package to do large calculations. I have, however, done some very large calculations with NWChem and have found that the MP2 and CCSD(T) implementations scale linearly with the number of cores for a very long time. The triples part of CCSD(T) is actually known to scale linearly to the entire size of the Cori supercomputer at Nersc as implemented in NWChem.
My personal experience is that Gaussian does not scale particularly well with the number of nodes. I think most people use Gaussian for DFT though, which I have never done, so take this statement with a big grain of salt.
I have also used Molpro and out-of-the-box, it seems to be a very fast code. So, if you are only interested in single-core speed, I would guess that Molpro will fare very well. Their MCSCF implementation is famously good in my experience as well.
Also, Psi4 is an excellent, modern electronic structure package which seems to have been made with parallelism in mind, so I would think it will scale better than many packages.
This is why generally, for gas-phase ground state electronic structure I think Psi4 and NWChem are the way to go. They seem to be well-written and are free.
Generally, though, getting fair comparisons of the speed of two programs which implement the same method is very difficult. If you want to benchmark DFT, you need to use the same grid for each calculation, you need to run them on the exact same core of the same CPU. You need to make sure nothing is happening in the background of the computer you're running on that could interfere. You should run each calculation many times.
Something like HF is even harder to benchmark fairly because HF is an iterative method. So, the initial guess you use, as well as things that accelerate iterations such as DIIS, make a big difference in how long the calculation takes. Also, when comparing, you need to make sure the integral thresholds are identical since most electronic structure programs will throw out certain integrals which are guaranteed to be smaller than some value. Also, for a large calculation, you need to be careful to make sure that the integrals are stored in an identical manner since sometimes the integrals are stored in RAM and other times they are stored partially on disk and still other times they just aren't stored and get re-calculated.
For all of these reasons, performing a good-faith comparison of the speed of these packages is nearly impossible. Also, I would argue that the scaling matters much more than the zero-order speed.