You misunderstood something then. The goal was never to make a single CPU and a single (similarly priced) GPU exactly equal. In fact, if I recall correctly from the Zcoin Slack, they actually aimed for a 1:3 ratio. The reason for this is that there are ways to achieve vast amounts of CPU hashpower (AWS, botnets, etc.) that don't exist for GPUs, so GPUs should always have an advantage. Just not an orders-of-magnitude advantage.


I think you misunderstood something there, too. mjosephs was frustrated about the existence of the time-memory-tradeoff attack vector in the first place, and about the code change that was implemented in response, and uttered a suspicion that this fix is only a 'band-aid'. That's speculation though. There is no published research that indicates this. Reuben responded very fairly and admitted that, since MTP is still an extremely new development, it's possible that new weaknesses will be found that allow for new TMT attacks, but the Zcoin devs haven't remotely exhausted their options in this regard, so basically there's no need to worry.

Also, perhaps I should point out to you that literally nothing you do in computing is 'fundamentally memory hard'. You can always exchange memory usage for CPU time (because whatever you save in memory, you could also just re-calculate whenever you need it again). That's one of the basics of computer science.
So the question isn't whether an algorithm is 'fundamentally' memory-hard (a concept that doesn't exist), but whether it is memory-hard in practice, i.e. whether there is a practical method to use much less memory while using not much more CPU time. That's why it can be sufficient to remove such a practical method with a minor fix. And that's why, once such a method is fixed, we are back to square one and there is no way of reducing the memory consumption of the MTP algorithm without blowing up computation time by an unreasonable factor – too large to make ASICs feasible.