If the keybase tool uses certificate pinning and if keybase.io is using SSL (likely), then a compromise of your connection would also need to be a compromise of the keybase tool on your machine (to defeat the certificate pinning, though if they can compromise the tool installed locally, you have other things to worry about).
You are right however that keybase.io themselves might be compelled by the government (or criminals if you make a distinction there) to serve up modified public keys.
If keybase.io provides a modified public key, doesn't the client detect that by comparing a hash of the provided key to the "proof" hash posted elsewhere?
e.g. In the situation commented above [1], your client would download the altered key from keybase.io, compute a hash, then download https://twitter.com/bob/tweets/1234 and extract THAT hash, then compare the two. The comparison would fail, and you would know that the key you received from keybase.io is not the same as the key that the tweet vouched for.
And certificate pinning means that they store whatever public key was reported for maria the last time, and complain if they're different? I see that that would help.
I would even go farther and include the expected public key directly in the client. That would even defeat attacks where the connection is already compromised the first time you run the client.
You are right however that keybase.io themselves might be compelled by the government (or criminals if you make a distinction there) to serve up modified public keys.