It certainly depends on the threat model, but in this case I have to agree with Github---adding at-rest encryption would be unlikely to make their product significantly more secure, and it would certainly be nowhere as secure as Keybase.

With Keybase, the data is encrypted on the client, and the keys stay on the client. Assuming the crypto is done right, there is fundamentally no way for Keybase to read the data, and therefore no way for an attacker to get the data by way of compromising Keybase. The only way for an attacker to get the data is by compromising the client machine, which is a very different threat model.

With the model you're proposing for Github, the data would be encrypted for transfer (via HTTPS or SSH), but then it would be immediately decrypted again on the server. Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.

Personally, I appreciate Github's stance on this. There have been a number of "secure" products (see e.g. Lavabit) that have really been snakeoil because they used the approach above. I'll take honesty over false promises any day---at least with the former, I understand my risk and can take steps to mitigate appropriately.