The way Kerberos works is by the client (browser, app, PC, etc.) requesting a ticket from the KDC (domain controller) whenever it needs to log in to the SaaS application. The KDC creates the ticket and encrypts it to a key only the service knows. Therefore this means the client must have line of sight to that KDC whenever it needs to log in. Within a corporate network this is completely reasonable and is how many apps have functioned for the last 20 years.
However, what happens if the client doesn't have line of sight, say working from home because of a pandemic? In that case the client needs VPN or a KDC proxy to fulfill the requirement. Not unreasonable, but more infrastructure to deploy. Comparatively things like cloud identity providers don't really have this issue (though introduce their own).
Regarding the security of the symmetric key... Only the KDC and the service should have knowledge of that key, so therefore only the KDC or the service can generate a ticket representing the user. The KDC is authoritative so it's going to issue a ticket one way or another and the service is the thing requiring the identity so who cares if it impersonates something only it cares about? Repudiation might be important on that one for the sake of auditing, though you could argue that if the KDC didn't log a ticket creation did it really happen? Also, in Windows-land domain controllers sign an internal bit of the ticket with a key only the KDC knows so with enough auditing it's possible to prove one way or another if the KDC issued the ticket.
Since only the service knows that secret, the best it could do is potentially authenticate itself to the KDC and from there request a ticket to another service, but it's going to be the identity of the service so it can't impersonate other users. Unless you enable full unconstrained delegation. Just don't do that. A SaaS should never need that.