Full disclosure: I was the Program Manager overseeing Kerberos for a while, and am currently a developer actively working on it at Microsoft.
What you're describing is not strictly accurate. Kerberos as originally spec'ed does rely on symmetric crypto for authentication. However, there are widely used extensions to this spec that enables support for PKI authentication and defeats client *-roasting. Windows for instance uses the PKINIT extension for smart card auth and Windows Hello.
Additionally, the weakness is not that secrets are symmetric, but that the secrets are often user-generated which means easily guessable or they've chosen a weak cipher suite. Switching to an asymmetric crypto-based protocol just moves the problem from "how do I generate keys" to "how do I store and protect keys". In practice both are equally difficult problems for different reasons.
Asymmetric keys also don't solve golden ticket-like problems. If you're in the position to steal the krbtgt symmetric secret, what stops you from stealing the asymmetric secret? Not a lot. If you're in the position to protect an asymmetric key, why aren't you in a position to protect a symmetric key? In fact many systems today use symmetric secrets for protecting these types of tokens, such as session cookies or refresh tokens because of the performance benefit. Making it asymmetric doesn't directly improve things (though app architecture could dictate otherwise).
Silver ticket problems do benefit from moving to asymmetric because a service would never need to know the private key, which reduces the likelihood of it leaking.
However, in doing so you give up a guarantee of mutual authentication. Symmetric algorithms have the property that because both parties know the secret there's mutual authentication (the system falls part when multiple parties know it). With asymmetric keys there's no guarantee the party that receives the ticket is actually who they say they are. You need to explicitly authenticate both parties now, which can be done by adding another asymmetric key, but now you have at least doubled the total number of keys required in this exchange. You're still stuck protecting a secret on both sides.
The alternative of switching to another protocol is also practically difficult to accomplish. There are systems that simply will never move, and the systems that will move will do so over many many years. This requires involving lots of standards bodies, software implementers, and companies, and convincing them all that is best. That's not to say it's impossible or even a bad idea. Just that the effort required to do so and succeed is enormous.
Alternatively you can make minor adjustments to how Kerberos is used today and have Really Good (tm) security.
- Ditch Passwords (smart cards, Windows Hello, FIDO, etc.)
- Use strongly generated service account passwords (gMSA, etc.)
- Disable weak ciphers (DES, RC4)
- Enable compound authentication (armoring)
