What are the use cases for defining something other than the default SHA1 hash in a CSR? Is it to protect the digital signature, public/private keys? What is it protecting exactly?
It's actually not a SHA1 hash in the CSR. It's a signature of the message.
For simplicity, I'll assume we are talking about RSA certificates, where the public key is (N, e) (the modulus and public exponent which is typically 65537) and the private key is (N, d) (the modulus and the private exponent which can be easily calculated via Euclid's extended algorithm if you can factor the modulus into p and q).
A certificate is simply a public key, with some meta-data (e.g., who you are, what domain the certificate applies to, who signed the certificate), plus the signature of the certificate.
In RSA you sign a message by attaching a signature to the end of the message. You obtain the signature by first hashing the message and then doing modular exponentiation on that hash with your private exponent. That is the signature is
S = H(m)^d mod N. Note anyone with the public key can verify the signature by calculating
S^e mod N and verifying that this matches the hash of the message. Note, if you do not have the private key you cannot construct a valid signature for the message, so this prevents tampering with the certificate.
A CSR is a certificate signing request, but essentially it is just a self-signed certificate that you create on a local machine, so you can give to a CA to sign (so the CA will never learn your private key). So you locally construct two large primes, multiply them to find the modulus, and calculate the private exponent. You add your meta-data about yourself to your CSR. For good measure, you immediately sign your certificate with the private key associated with the public key contained within the certificate.
This prevents someone from altering your CSR in transit to the CA (to say change your organization details, challenge password, serial number, without changing the modulus/private exponent).
This probably isn't the most devastating attack as you still have to trust the CA to act in trustworthy manner, and there's no reason to give away your CSRs to any other third parties. However, its straightforward to sign it, takes no additional effort, so it is commonly done.
The RFC for CSRs - https://tools.ietf.org/html/rfc2986 - actually gives a different reason why the CSR is signed. It doesn't say anything about preventing the CSR being modified in transit, but says that it is to prevent someone requesting a certificate for a key that is not theirs (and says this is only a minor issue):
" Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does not know the message being signed and the signed part of the message does not identify the signer. The entity would still not be able to decrypt messages intended for the other party, of course."
(on page 4).
I don't think the 'prevents the CSR being modified in transit' idea actually makes much (or any?) sense. So far as I can see, any practical MITM attack requires the attacker to be in a position to intercept the communication in both directions, whereupon they can just substitute an entirely different CSR for a key pair they actually control the private half of.
I can't see a plausible scenario where any kind of plausible 'attack' can be carried out by a party sitting between a CSR submitter and a CA who can't change the public key, unless you're positing an attacker who would somehow gain something from fiddling with the certificate metadata and a submitter who doesn't bother checking the metadata on the certificate that comes back from the request...