Having a fast malloc less compression library is extremely useful in resource constrained embedded systems world, where either memory usage should be minimized (you can still run modern Linux kernels on systems with 32MB of RAM, probably less), or where traditional memory management isn't available, such as a microcontroller.
In the microcontroller case you can get a 32bit ARM Cortex M0 for $2.00 qty 1 these days, allowing the bit-twiddling you find in compression libraries to compile successfully. Having a fast malloc-safe compression library is extremely useful. lz4 is an example of one which you can run on a microcontroller successfully, but isn't as compatible as zlib is.
hey, this answer was really interesting! I was actually making a (poor) joke about the quixotic idea of requiring a desktop program to be just fine with malloc failing, no biggie. your answer is much more interesting.
Large embedded systems also like malloc-less solutions. In such systems you essentially have explicit use for all the memory you have and you don't like to buy extra memory that is unused (reduces your margins). When you need to account for all memory needs and you use allocation schemes you need to create memory pools that are not too large (create waste) and not too small (performance bottle or deadlock source).
One such example are large SAN storage systems. We can have gigabytes or even a terrabyte of ram and still have very little spares (little by our standards < 100MB for diagnostics and general OS nuisance).
In the microcontroller case you can get a 32bit ARM Cortex M0 for $2.00 qty 1 these days, allowing the bit-twiddling you find in compression libraries to compile successfully. Having a fast malloc-safe compression library is extremely useful. lz4 is an example of one which you can run on a microcontroller successfully, but isn't as compatible as zlib is.