I had a kind of lame "rationale" at the time for choosing sha384 instead of sha256 and still producing a smaller key, but in my defence I wasn't sure I'd get such a great response from the Mumble team. That rationale was that maybe a shadow larger than 256 bits wouldn't make you guys happy, and since speed is actually the elastic factor regarding KDFs, a hash smaller than sha384 wouldn't really make me happier, so I thought "a compromise!" and, it still would yield a little bit more security than sha256 would.
As for information about the preference for a truncated version, the closest I could give you is that since PBKDF2 doesn't use SHA directly but through HMAC a hash length attack wouldn't make precomputing clear texts much easier even knowing every salt, so sha384 doesn't appear 'critical' in any way (as it would be without relying on HMAC, see http://vnhacker.blogspot.com.br/2009/09/flickrs-api-signature-forgery.html ). I believe storing a full sha384 length shadow would be a bit better, since it is already truncated.