It's right in the key!
> Do I really need to copy the key or .asc address, wget it and import?
Is this a failure of keybase? You import it as with any other key, "decrypt from clipboard" in your favorite manager, or similar.
> How do I know if that's your latest key?
I don't know, how do you know that with a keyserver?
> Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog?
Again, same as any other keyserver.
> THERE MUST BE AN EASIER WAY!
It seems that the frustration is with the PGP client, rather than keybase or the server, though.
It should probably be easy to presume that if a user gives you their Keybase username they are telling you it's the easiest way to get their most up-to-date key(s) and revocations and that they are actively managing it. (Pretty much the same assumption any time anyone ever suggests to you a specific keyserver over just a fingerprint and keyserver roulette; that's probably the keyserver they actively check/update/revoke and will be the timeliest.)
Another example of the walled garden. You need their tool, whereas you can just use gpg with every other keyserver.
Maybe consider contributing to the effort?
Quick searched turned up several issues tracking the question:
https://github.com/keybase/keybase-issues/issues/327
Or if you read the issues you can see that there are some genuine concerns in there that you could help contribute to that would benefit the open source community as a whole, with the side effect of simplifying things for Keybase "as well". Primarily, from skimming, it sounds like the keyserver protocols are not as well documented and standardized as one would assume, running a keyserver from a fresh/new code base is a non-trivial matter with a lot of quirks/bugs to handle. So, who knows, maybe you could contribute to better documenting keyserver quirks, and pushing for better, less quirky, keyserver standards.
Revocations are a big problem.
As browser PKIs have demonstrated, revocation lists are basically insane and absolutely Do Not Work at scale when keys are able to live for years.
The endgame with browsers was that the cert revocation lists basically aren't checked. Hooray.
More fundamentally, revocation (even if it was scalable) is fail-unsafe. If someone can block your connections to revocation info sources, they can get you to perform unsafe operations. It's not a stretch to say that this is an absurd problem when we're trying to roll out secure cryptosystems: a network DoS should not crack open my security.
This is something TUF -- http://theupdateframework.com/ -- tackles with their timestamped re-assertions. It limits the amount of time that you can fail-unsafe by after seeing a revocation... to a tunable parameter, perhaps days or even hours, instead of years. At the same time, you get to keep your long-lived keys (you don't have to constantly update everyone on new keys).
We should learn some tricks from TUF for our personal comms PKIs. It would solve a lot of problems.
Ehh screw that. I'll write it in plaintext.