+2  A: 

The technical reason is as follows:

The Kerberos protocol in its basic form does not provide perfect
forward secrecy for communications. If traffic has been recorded by an eavesdropper, then messages encrypted using the KRB_PRIV message, or messages encrypted using application-specific encryption under keys exchanged using Kerberos can be decrypted if the user's,
application server's, or KDC's key is subsequently discovered. This is because the session key used to encrypt such messages, when
transmitted over the network, is encrypted in the key of the
application server. It is also encrypted under the session key from
the user's TGT when it is returned to the user in the KRB_TGS_REP
message. The session key from the TGT is sent to the user in the
KRB_AS_REP message encrypted in the user's secret key and embedded in
the TGT, which was encrypted in the key of the KDC. Applications
requiring perfect forward secrecy must exchange keys through mechanisms that provide such assurance, but may use Kerberos for authentication of the encrypted channel established through such other means.

Basically perfect forward secrecy adds additional overhead to the protocol that is not necessary for many of its applications. If you need PFS, then you can add it. What does matter to most Kerberos users is speed. If you have tens of thousends of employes all over the world all authenticated at the same time, then the overhead required for PFS is going to be too expensive and there for not practical.

Rook