Well, they put in the time to test a massive cascading delete operation. Surly a flag would have offered far less possibility of catastrophic outcomes and therefore would been significantly easier to confidently develop and test.
Cascade delete is a less risky operation from a security stand point. There are so many edge cases where potentially sensitive information could get leaked with regards to subscribed private repos if not handled correctly. In fact I have personally filed a bug bounty with GitHub after discovering just such a bug.
I’m not saying there isn’t a better way Github could handle this situation. Just that I do sympathise with the decision to cascade delete.
If they are using a database's built in support for cascading deletes, and if the star tables are simple m2m tables (basically just 2 fk's per row), the work to implement and test cascading deletes is trivial.
