It is true that many memory-hard functions (MHFs) only give a time-space tradeoff. Take the example of
scrypt, which was proven to have optimal cumulative memory complexity $\Omega(n^2)$ in:
Joël Alwen and Binyi Chen and Krzysztof Pietrzak and Leonid Reyzin and Stefano Tessaro: Scrypt is Maximally Memory-Hard. Eurocrypt 2017
Cumulative memory complexity only counts the sum of memory usage over the length of the algorithm. It does not preclude an algorithm taking $O(n^2)$ time but only $O(1)$ space, and indeed it is not hard to see that
scrypt does have such an algorithm. From what I understand, this is how it is implemented by most ASICs, so the "optimal memory hardness" (paradoxically) does not prevent folks from evaluating it using basically no memory.
This odd situation is what has inspired more fine-grained definitions of memory-hardness, for example sustained memory complexity:
Joel Alwen and Jeremiah Blocki and Krzysztof Pietrzak: Sustained Space Complexity. Eurocrypt 2018.
Sustained complexity allows you to say things like "to evaluate this function you must use $\Omega(n/\log n)$ amount of memory for $\Omega(n)$ steps." So this is a step in the direction that you suggest.
To answer your specific question:
Computational complexity tells us that if a problem requires a lot of memory to run, then it also requires a lot of time to run. Wouldn't these problems be better used as memory-hard functions than those with a time-space trade-off?
This is more nontrivial than it seems. There is a difficult asymmetry in the requirements for a MHF:
- The honest algorithm is a sequential algorithm that uses $n$ time and $n$ memory
- No parallel algorithm uses significantly less than $n$ time, $n$ space (and ideally requires both simultaneously)
So you have to find a way to rule out speedups from parallelization. And it's actually worse than that, since you also want to rule out speedups from amortization (solving $k$ instances with less $\alpha n$ time and $\beta n$ memory for $\alpha \beta < k$).