Good question, I'd like to know SeoxyS's reason, too.

Aside from the space consideration already mentioned, if I had to surmise, I'd guess it would be faster to process because we're skipping the encode/decode steps unless we are explicitly "importing" or "exporting" the hash, and less chance of making mistakes to encode/decode through Base64 before doing anything with the hash.

It is marginally more of a hassle to debug in a live production environment, though. When you are troubleshooting, grabbing the binary representation and running it through a Base64 decoder is annoying. Doing this from inside a mass file search to look for all instances of the same hash can be a bother.

I suspect we're storing as Base64 everywhere because so many hashes are held in XML files, and the standard strongly encourages storing binary within XML as Base64. Once they are doing it in an XML file somewhere, I gather lots of teams make that the canonical representation everywhere, even in a database when it isn't strictly necessary.

It's going to be a third bigger than storing the bytes directly - which doesn't seem that big a deal. Storing images or video base64 encoded in a database columns would be silly but for hash values I'd be inclined to go for something that is slightly easier to code against.

It's unnecessary CPU work and also takes more storage space in the database.

In practice I doubt that it makes much difference in terms of performance as hashing is way more expensive than base64-encoding. The rant is probably more against the misunderstanding of developers.