I'd argue this is barely worth the time spent. You'd use at least a hundred services of this sort, with a flux of at least one a week. 2-3 hours reading up on intricacies, setting up backups for your data? It's a crazy amount of time to spend on something you dont care about - you just want it to work.
If argue that if you care enough about the content that you'll do more than say "oh well" to yourself if it becomes inaccessible, then researching this sort of thing or (probably easier but maybe more costly in terms of bandwidth use) rigging it up to your existing backup infrastructure is the minimum effort you did make. If you don't you have no high ground from which to complain or blame others from if it going away inconveniences yourself.
If you don't care about it that much, why do you keep it anyway?
In this instance making sure that you understand the service you are using (including intricacies like this), or keeping an extra backup of your own (a locally cloned copy of the repo), or for proper paranoia, both of the above.
No matter how much you trust github and those in positions of responsibility for the projects you interact with, if you don't know the exact details of the feature-set you can come unstuck due to operating under false impressions. Github has done nothing wrong, as that is how the service is intended to work and it is documented as such (though it would appear some of the documentation is incorrect or at least inconsistent?), but you still get an inconvenient surprise because of a misunderstanding.
A little paranoia can be very useful!