Why aren't hash values for "nothing" (empty) defined as all zeros? Any decent hash algorithm will produce basically "random like" values for any given input including the empty input. 
For example MD5 produces d41d8cd98f00b204e9800998ecf8427e on an empty input.

I wonder, however, why the MD5 algorithm wasn't defined to have a final step where the output is XORed with d41d8cd98f00b204e9800998ecf8427e.
This should not affect the cryptographic strength of the hash algorithm, and it would have the convenient property that a hash of all zeros represented a zero input.

Would it simply just because adding that step would slow the hash down a bit?
Why would that be a convenient property? It would be pretty annoying if I would test an empty string input, hash that and then XOR it with a value. I would get the same value back. You want the output of a hash function to seem random; getting a value of zero is not what you want at all. You don't want any exceptions to the output of the hash function.

Imagine a crypto currency that requires the first $x$ number of bits to be set to zero for a crypto coin to be mined. You could just input the empty string to be rich beyond belief.

The only thing worse from having an empty string result in $n$ zero valued bytes is to have $n$ zero valued bytes return $n$ zero values bytes. Because in that case $H(0^n)$ would equal $0^n$ but $H(H(0^n))$ would as well, to infinity and beyond.

This would be called a cycle of 1 length; hash functions should never enter a cycle (in practice) when hashing the output of previous hashes. Of course, the hash function would not be considered secure anymore: $H(x) = x$ is called a pre-image and secure hash functions should be secure against pre-image attacks.