Kerberos assumes there's a out-of-band mechanism for bootstrapping and establishing trust with every participating server. More specifically: Every server needs to have a unique secret (symmetric) key, which needs to be known by the KDC. Distributing these symmetric keys is outside the scope of the Kerberos protocol, and often done manually.
If you're performing cross-domain authentication, there's also another level of interdomain keys needed to create referral tickets, which are also symmetric and need to be trusted.
This works well in an organizational setting, where everything in the known-world is centrally managed. It doesn't scale well to the entire Internet.
Kerberos is mutual authentication with a bootstrapping overhead on the client side (you need keys, and distributing them can be challenging) and makes heavy use of accurate time. It doesn't adapt well to that sort of use case, and works better with an IT department backing it up. The protocol itself is just fine over an untrusted network -- that's what it was built for -- but that's not the usage you see. The SSO aspect of Kerberos is very nice, but OAuth and others push more toward "federated identity," a slightly different take on the same thing.
Even beyond that, it's heavy. Arguably, that OAuth stuff is a bit lighter. That's more a taste thing. Kerberos, when executed well (see Google pre-BeyondCorp/etc), is awesome.
A very minor nit, the client (user) does not require bootstrapping or pre-shared keys. If your DNS for the realm you are kiniting to are correct, you can get your client keys without any client side configuration.
When a client kinits, no validation of the kdc is performed. As the kdc never gets the password, the most an invalid can do is issue you invalid keys, which will get denied by any service that sees them.
Severs require keytabs to validate user keys, and these can be much harder to distribute to all your servers that need to authenticate users.
Kerberos doesn't work through NAT, for one. (I think that there might have been an extension, but it never took off.)
Open ID Connect will support the more complicated "delegation" scenarios that Kerberos enabled. Think, authentication across multiple service boundaries. That kind of thing.
I used it to connect to campus servers back in college, through my home NAT.
There is an optional field in the Kerberos ticket that can contain your client address, as an additional point of validation to prevent certain classes of replay attack. That particular feature can conflict with NATs. But it's optional.
Why is Kerberos insufficient to solve the sign-in problem that we had to invent new protocols?