This can be applied to pretty much any security-focused product, or product claiming to be secure/encrypted. If it relies on an unknown number of proprietary/closed-source components, it can't be trusted. Keybase, WhatsApp, Telegram, and iMessage are all good examples of this. If your code can't stand up to public scrutiny it might not be able to withstand attack. I'm not willing to blindly chuck messages into a black box and hope what comes out the other end is exactly what I put into it. (This complaint is not specifically about Keybase; in fact the linked article and a few comments say their client doesn't trust the server at all, which is really cool. Point still stands.)
Keybase looks really really cool, and I would love to use it, but I can't in good conscience recommend something that is cagey about the half-open nature of their product, especially when the server. It is by definition "man-in-the-middle"-ing all your data, and if you can't inspect it you can't reasonably trust it.
> ...if you can't inspect it you can't reasonably trust it.
That is the point the article is making, and that's what it sounds like the Keybase client is doing--not trusting the server by relying on client-side encryption rather than storing keys on the server.
The fact that you can change keys and see old messages without the other party sending them to you using your new key points to serious problems with these other apps. It seems the Keybase client rightly considers the channel insecure.
Keybase looks really really cool, and I would love to use it, but I can't in good conscience recommend something that is cagey about the half-open nature of their product, especially when the server. It is by definition "man-in-the-middle"-ing all your data, and if you can't inspect it you can't reasonably trust it.