For algorithms, hands down number of nodes, assuming you are not solving numerous (MI)LPs/node (e.g. you are not doing strong branching). This is how we evaluate potential when we prototype new algorithms at Octeract.
The reason is that the steps performed per node can be optimised in many ways, while the number of nodes we need to explore is purely a result of the algorithm(s) used.
Computing time is not a very good one, because it's very sensitive to implementation rather than a result of the algorithm itself. I've achieved improvements of 20,000x just by optimising code for existing algorithms. If we were evaluating using time, those algorithms would never have passed the test, but after optimisations they were really good.
Computing time becomes a more relevant metric when tuning a solver with highly optimised code. Even then, a trained eye can identify steps to skip altogether without changing the overarching algorithm.
As people have pointed out there is merit to computing time, but I'll just give an example as to how misleading this can be when developing an algorithm. Say I have two algorithms, A and B. A converges in 100 iterations and 100 seconds, B converges in 10 iterations and 500 seconds. Closer analysis reveals that B is slower because the linear solver solving the relaxation gets stuck on one node and spends 480 seconds on that 1 node. Even though it's slower, algorithm B is clearly superior to algorithm A. B is simply slower because of implementation issues which can be addressed (e.g. by switching to a different LP solver).
This is not an academic example btw, we deal with issues like this every day.
Since you mentioned number of iterations, for a branch-and-bound algorithm that's pretty much interchangeable with the number of nodes, so either goes. Number of iterations is also the equivalent of what I describe for non-BnB algorithms, e.g., interior point. There we would care much less about cost per iteration (when it comes to evaluating the algorithm itself) than we would about the number of iterations.