The rest of GitHub runs on MySQL. As the rest of the post alludes, adding unnecessary complexity isn't what they are about (in this case.)
Basically, MySQL is a key-value store in an RDBMS's clothing.
Every time I've worked with mySQL I've seen some irksome behavior... just the same, setting up failover options is miles ahead of PostgreSQL. And when you already have in-house talent, it becomes even more obvious.
My only thought was that using a clustered database (such as Cassandra) as the store with the data itself might have been better. domain/url (minus querystring) would hash/distribute fairly well, and with even a relatively small cluster with 2 replica nodes for the shard would be pretty effective. Also, it would be easier to manage a replicated database, in my mind, than tracking sites to pairs of static servers. GoDaddy is/was moving to something similar with new development on one of their applications when I worked there, and able to serve a huge number of static requests (hundreds of thousands per second) off of a relative few servers with a sub 10ms response time, for content not backed by cdn.
In the end it just goes to show that serving static content on modern hardware can scale really well, with a number of options for technology. Which is why I'm somewhat surprised that something hasn't taken over the tide of poorly configured Wordpress blogs.
Just because most of the comments here have been (bizarrely) pro-MySQL, I have to link to this article:
So, if their team have lots of experience with MySQL but not so much with PostgreSQL, that could be a good reason to prefer one over another.