About two years ago, a community college near me had the exact same thing happen. I don't know the excruciating details, but the basics were the same SCCM wiped out all of the servers that it was used to manage..
I didn't work for the college then (I do now), but I did know a few people that did at the time. The person that triggered it is still there. From what I understand what he was doing and the way he went about it, although in hindsight was dangerous, wasn't a really reckless thing.
Our campus is less than 30 minutes drive to Microsoft's main campus, and there was a lot of pressure for us to use their systems. I think the college paid the price for caving to that pressure. Sure, there are other factors involved here as well... A careless employee, an unintuitive result from an interface/script, poor safety mechanisms in both policy and the product, poor design by both the vendor and the college..
From what I understand, one of the most devastating aspects when it came to recovery, was that the server that held backups (Microsoft's data protection manager of course) was wiped out as well.. I think in this particular incident, only system drives were annihilated, so if a server had a "D" drive or other volumes, it was still there, it was just a useless lump sitting on a server with no OS for a while at first.
Having never heard a similar story with any other software product, I'm left believing that SCCM and it's deficiencies are at least partially to blame, and given what I know about the person that caused it here, I'd say that it's a pretty respectable bit of the blame that should be left on SCCM.
Someone realized pretty quickly what was going on (not the person that caused it), and pulled the plug on the process somehow or our college would have been even more devastated. As it stood, it was still pretty bad.. Probably only about 25% of the full destructive power of the mess as averted.