Which risks are associated with deriving multiple keys from the same DH secret Z? NIST recommends Krawczyk's HMAC-based key derivation function (HKDF) in SP-800-56C (PDF). HKDF shall e.g. be used to create keys from shared secrets after Diffie Hellman key establishment. 

NIST states in the same doc:


  Each call to the randomness extraction step requires a
  freshly computed shared secret $Z$, and this shared secret
  shall be zeroized immediately following its use in the
  extraction process.


Why is it not recommended to derive multiple keys from the same $Z$, e.g. why not derive a key for data encryption and a key for authentication from the same $Z$ using different info strings? If I still do it, what weaknesses might the derived keys be facing? Is it simply bad practice (without deep explanation) to do so since the derived keys obviously are related? Krawczyk seems to think that multiple derivations from the secret are expected use (see section 3.2 in RFC 5869, my interpretation).

Does salting the HKDF with a good random salt change my risks when deriving multiple keys from a single $Z$?
It depends on how you use HKDF to derive multiple keys.

Background: HKDF consists of two stages: first HKDF-Extract computes an intermediate value from the randomness source; then HKDF-Expand can be used to generate one or more session keys from the intermediate value.

The right way is to use HKDF-Extract once, and then call HKDF-Expand multiple times, with multiple different info strings.  In other words, to derive two session keys, you'd call HKDF-Extract once and HKDF-Expand twice.  If you do that, then this is a perfectly good practice -- it is exactly what HKDF was designed for.

The wrong way is to call the entire HKDF process twice, with two different salts.  Some implementations of HKDF might not separate out the two stages, and just combine them; if you used that, and performed the entire process twice (using HKDF-Extract twice and HKDF-Expand twice), then this is not the intended way to use HKDF.

Everything is fine if you use the "right" way, so for the rest of this question I assume you were asking about the "wrong" way.  There are two answers about whether this is a good idea: the "engineering" answer, and the "principled" answer.

The engineering answer is that, in practice, if you generate two keys using two different info strings, I suspect you'd probably get away with it without problems.  If we model the hash as a random oracle (admittedly a very strong "assumption"), then I suspect it might be possible to demonstrate that what you propose is OK.  Disclaimers: I haven't analyzed this, and I'm certainly not going to give you any guarantees -- if you do what you propose, cryptographers will wag their finger and say "tsk, tsk", and rightly so.  I suspect you'd probably get away with it (it's not the worst sin you could make), but if something does go wrong, cryptographers aren't going to take the blame -- it's all on you.

The more principled answer is that if you do what you propose, you are misusing the HKDF primitive.  The HKDF is only intended to be applied to a single $Z$ once.  It is intended to turn an unguessable value into something that looks uniformly random.  It has been analyzed for that use.  It was not designed to derive multiple keys from the same $Z$: it hasn't been analyzed for that kind of use case, since that's not what it was designed for.  So, you're throwing away the benefits you could get from the public analysis of HKDF if you use it in a way that it wasn't designed for.

Consequently, given that it is so easy to use HKDF the right way, you should probably do that.