thank you for looking into this issue.
From my point of view there are two main reasons to restore the documented ksu behaviour:
1) to not perform useless requests to TGS/DC, to spare resources; performing the TGS requests also raises the ksu execution latency..
2) from a security standpoint, to reduce the potential "attack surface"; this point is far more important to us, let me elaborate a bit:
A potential attacker may, in a limited time window, have the opportunity to stole the cached krb tickets. One TGT permits the attacker to impersonate the user for all resources/services in the domain; a service ticket (not forwardable) limits the attacker to impersonate the user only on the current host/service.
Taking this into account.. in order to use ksu.. we would like to populate the Krb cachefile only with the end-server service ticket (the cachefile should not contain a TGT).
At the moment we populate the cachefile in this way thanks to the kinit command with the -S option.
kinit permits to request an "initial" service ticket (In the future we will try to implement a way to populate a cache file with a service ticket acquired thanks to a TGT--stored in a different safe place--).
Security is a key point of our work, the documented ksu behaviour looked exactly what we need.