This is something I thought FB would be in a better position to do a while back: http://zalberico.com/essay/2016/03/23/Facebook-and-Public-Ke....
Though I guess most have just moved to walled garden encryption models instead of GPG - Moxie talks a bit about that here: https://moxie.org/blog/gpg-and-me/
The Design Overview does reference the fact that a user would have account credentials, and suggests that an attacker would have to compromise those credentials in order to change the keys on the user's account. So that's good. But that's still a single point of failure.
Compare this with keybase.io, where if an attacker compromises your account, they can't associate a new key with e.g. your twitter account thus tricking anyone who knows you over twitter into using your new key (they'd have to remove your twitter account from your profile in order to change the key). So keybase.io uses the variety of social networks as proof that your key really is owned by you, whereas Key Transparency seems to rely entirely on other people noticing via the key transparency history that the keys on the account all changed at some point (which doesn't necessarily even mean the account was compromised, it's possible the user did that deliberately because e.g. they lost control of their private key).
Note: I must repeat that I gave this only a cursory glance, and I didn't pay attention to some of the potentially-interesting properties here such as privacy protection. It's very plausible that Key Transparency does have valuable properties that keybase.io doesn't provide.
It's already implemented in Android OpenKeychain.
How is this different than KeyBase? It is similar. Some differences include the use of ZKP, it is a generic key store designed (could be used for PGP or E2E messaging), it is designed to scale to trillions of entries, anyone can run a log, and architecturally it should scale significantly better. KeyBase is doing great work, though.