Security implications of slow-by-design hashes on relative security vs. hash size
You CAN get away with using less memory if the hash is expensive. However, that does not mean you should, and it would rarely make any sense.

So why would you try to "get away with" using smaller hash functions? You could save some storage space, which is definitely appealing. However memory is cheap, and using larger hash functions adds more security, it also has the benefit of being more future proof than a smaller hash.

But in the end, it depends entirely on your data. There are many uses for hash functions, and using a slow hash with ASIC preventative measures for a checksum would be silly. However, if you are storing passwords in a secure database, you would want to add a salt and/or pepper and use an ASIC-safe slow hash.

I also want to address a couple misconceptions:


Your example does not make much sense. A rainbow table is a set of pre-computed hash chains for some expected plaintexts. This means that you could compute a rainbow table for a 1024 bit function for a small factor more memory than a 128 bit function. And if you add a salt to all of your data, it becomes infeasible to use a rainbow table at all.
You say "any partial break of the algorithm is more likely to be devastating" Why is this? A flaw in a hash algorithm is a flaw. Assuming the search space is reduced, the more bits you have the safer you are; however this does not necessarily mean any flaw is "devastating", a flaw is nearly as likely to be devastating as in a larger hash function.