The reason for not including pk_enc in the KDF input for Sapling is to support diversified addresses. That is, pk_enc varies between diversified addresses for the same ivk, and so the KDF must not depend on it, in order for an ivk to be usable for decrypting ciphertexts to any corresponding diversified address.
The rationale for adding pk_enc to the KDF in Sprout was, if I remember correctly, that we believed it might be necessary for IND-CCA2 security and/or for post-quantum privacy (in the case where the quantum attacker does not have the public key). Actually it is not needed for either of those; for IND-CCA2 this follows from the DHAES security proof, and for post-quantum privacy see [Sapling] diversified addresses · Issue #570 · zcash/zcash · GitHub . The latter was the more important issue since I think I already knew that pk_enc wasn’t required for IND-CCA2 when designing Sprout, and was just being cautious/conservative about that. (Including epk as an input, as in DHAES, is necessary for IND-CCA2 security, and Sapling still does that.)
The weak-PRF thing was just a nice-to-have that weakened assumptions on the hash; it was not necessary for security, since the stronger assumptions are entirely plausible for BLAKE2b-256.