Which I can't imagine to be any more reliable than hosted GitHub.

But hey, I guess there's the comfort in know that when it goes down it's our fault!

The argument is with a self-hosted solution you can choose your "danger times".

If you know you have a major deliverable coming up, you can choose not to touch your git server until it's at a somewhat safe moment to do so.

While it definitely sounds like a good idea, every single time I've seen it applied, the reason was the opposite. It was essentially "we've got so little control over our stuff that we'd rather not touch". Mostly goes along with lack of backups, lack of change management, and lack of automated rebuild procedure.

If you have "danger times", then any unplanned disruption in that time will hurt so much more.

I agree with you, and I'm generally in favor of having 2 or more ways of doing critical things if possible, just pointing out the response which can have some merit.

There's no ha for github enterprise. Single instance with hot failover.

Redundancy provides availability more than reliability.

The odds of GitHub going down and your local copy/instance simultaneously is very low so availability is high.

Reliability is how often GitHub or your local instance goes down.

Your local instance of github and github.com are not redundant / interchangeable. If either of those goes down and you rely on it, the other one is not gonna help you much, so availability is not improved by using a local instance.

Reliability can always be improved... It just costs more.