Practicality of compressing data with hashing algorithms
This idea is not practical, because there are some serious problems:  


You have to calculate all interesting hashes (less than hash length, here 128 bits), which is infeasible.
There must be a way to tell apart compressed and not compressed strings, so some kind of terminator or escape sequence must be introduced.
Since hash functions are designed with avalanche effect (small change in the input should yield huge difference in the output) there are no shortcuts for computations.
The preimage resistance prevents from fast reversing, given hash calculate the input, this also gives another problem, once the data is compressed, the decompression also requires full hash -> input mapping.
The hash signature is quite specific, there are almost none naturally occuring natural texts with such substrings.
If you want to use them in cascade it will be greedy approach, optimal one would require to calculate all cases to given depth and choose the smallest
Multiple hashing algorithms enhance the additional description sequence, now the simple one bit (compressed or not) is not enough, it should also encode which algorithm was used.
With collisions, the number of available hashes of given length decreases. The guarantee of better hash increases the complexity (both time and code).


The idea itself may be tempting, but it is not practical enough to be used in the common compression software, this tells quite a lot.

Please see also Compression with PRNG and Collision free hashes to compress and the compression of random data