The algorithms themselves just output binary (i.e. bytes) if you read their specifications. It's the implementation in API's and applications that output the hexadecimals and/or base64.
Sometimes there are also ad hoc standards / common practice that specifies a certain output format. This is for instance the case for the output of the bcrypt password hashing algorithm. In that case it's not just the hash that is displayed but also the type of algorithm, number of iterations and if course salt.
Base64 is more efficient than hex, while hex allows developers to easily see the value of the encoded bytes. The value of the bytes as well as the amount of bytes are just easier to see in hex; the amount of stored bytes is for instance simply half of the displayed hex digits. However for textual formats or indeed larger hash values base64 may be chosen for its efficiency (~33% overhead for base64 vs 100% for hex, assuming each character occupies one byte).
The command line utilities
sha1sum and their successors have always kept to outputting hex; it's to be expected that hex is therefore more likely to be output by applications that want to remain compatible.
Note that I've changed the case of the terms "Base64" and "HEX" in this answer to lowercase to be compatible with RFC 4648: The Base16, Base32, and Base64 Data Encodings which tries to standardize the encodings. It only uses the uppercase variant in the title. "Hex" is an abbreviation, not an acronym, so all uppercase does not make sense.
Personally I prefer all uppercase for hexadecimals; people recognize the upper part of letters / digits more easily, so it makes sense to use it as default (and on all my old computers the characters were also in uppercase, so they are in most debuggers).
Note that many (online) tools do not clearly specify the input / output format. In that case it makes sense to look for better tools rather than trying to find out what kind of format the tool accepts.