Problem is that
AES is not suitable as a hash (certainly not when employed as encryption) for it has too small of a output space (repeating patterns will be over a few number of bits), thus it will be possible to attack this with an algorithm to reduce the scratchpad size significantly from the 2MB.
I agree with this. Only a small number of bits of the output of AES are being used, but AES does not guarantee that all of its output bits are random. For example, consider an algorithm AES' which is just like AES except that it appends 10 trailing bits that are always zero (AES'(x) = AES(x) << 10). This would be just as secure as AES for encryption, but catastrophically bad for slow_hash.
I suspect the developers wanted to use AES because of the hardware support in Intel CPUs, but they made a mistake, though it isn't immediately apparent how catastrophic this is (unlike my toy example above for example). If they used a true secure hash, it would be much slower and likely not memory bound.
The algorithm can and should likely be improved in this regard, although I don't have any immediate suggestions how.
What kind of comparison can be made with Tromp's Cuckoo Cycle (Man, that's painful to say -- sorry Tromp), or the blockchain mining style that's proposed in HoneyPenny in light of the weakness in AES?