Devil's avocado here: let's say you pay $100/mo for a gym membership and they shut down three days in a row because somebody called in a threat. How upset would you be at the gym?
A malicious attack by a third party is different from, say, the gym allowing black mold to grow in the locker room. I'd quit a gym if they had black mold. That's mismanagement. I wouldn't quit a gym if malicious third party intervention inconvenienced me.
Besides, GitHub is obviously more concerned about this than you or I could ever be. And having money doesn't make infrastructure magically appear.
I pay GitHub too. My company relies on it. I, too, was slightly inconvenienced this week. I was also slightly inconvenienced when I had to make a u-turn because the Battery Tunnel southbound on-ramp was closed. So what?
What makes DDOSes different from black mold? Both are expected risks and should be mitigated. Yeah, there are sentient actors behind the DDOS, but GitHub has to deal with it at the level of their infrastructure either way.
The fact that there are sentient actors behind the DDoS _is_ the difference.
You can reliably predict and protect against things like network outages, server failures, full datacenter failures (black mold)--you can directly measure their impact and plan failover paths. A DB server goes out? Whatever! That's why you have a hot backup or two online and ready to go.
What you can't predict is exactly how far a malicious third party will go to hurt you. You can't predict how many dollars they'll spend on their botnet minutes. You don't know if they're going to attack your infrastructure or the DNS. Can buying more bandwidth fix the problem? If so, how much more? And will the attacker simply up the ante when they see that you're recovering? Can filtering requests fix the problem? If so, will the attacker provision different resources to attack you with?
This isn't simply a matter of infrastructure, buying the right equipment, or setting things up "just right" precisely because there is a sentient actor trying to hurt you. It's more like a game of chess.
If high availability git is so critical then why not run your own git servers instead of or in addition to github?
I find it slightly ironic that the entire point of git is that it is distributed version control but 90% of git use seems to be focused around a product from a single company.
The wikis are git repos as well. Sync them periodically and you're good. Plus it's useful as a backup, because I don't think github archives your reflog.
Issues are normally mirrored to e-mails (caveat: you don't get mail for your own comments), so you can mostly pick up existing threads if your e-mail address book can find the github users involved. If they didn't obscure recipients (at least within an organisation — because I don't think address-book lock-in is worth inconveniencing paying clients), and made an auto self-bcc of your activity, issues would be entirely disaster resistant.
If you have GitHub enterprise, it is run on your stuff and you get your own Wikis, issues, unlimited repos, etc. Even your own Gist that you can wrap behind your own CAS.
Since never. At least for businesses that want to remain an ongoing concern.