(A) It's decentralized! Woohoo! (I'm paraphrasing.) Which tells me nothing about why "decentralized" is better than GitHub.
(B) It's distributed! Woohoo! (Again, I'm paraphrasing.) Which, again, tells me nothing about why "distributed" is better than GitHub. Not to mention that "distributed" is not the same thing as "decentralized", so if I'm supposed to prefer something like dgit because it's "distributed", the goal posts have been moved.
(C) If GitHub goes down, you can automatically switch to pushing to <other place>. Which amounts to "this solution has better failover than GitHub", which, as I noted, (a) might or might not be true (I'd want to see your uptime numbers), and (b) has nothing whatever to do with <other place> being "decentralized" or "distributed" since "decentralized" has nothing to do with failover reliability, and GitHub is just as "distributed" as <other place>.
(D) You can keep all the "non-git components" in <other place> along with the git repo. Which might be an advantage if it's easier to get them from <other place> than from GitHub, but, again, has nothing to do with <other place> being "decentralized" or "distributed", it just has to do with how accessible <other place> makes the "non-git components" as compared with GitHub.
Is there an (E)?