I've been nothing but impressed with DO, right now there seems to be a misunderstanding and OP is not providing full details nor is he allowing DO to discuss what happened.
If he truly cared about others not using DO he'd allow it to be discussed, but it does seem like OP is hiding some fact...
So now I'm left with great service and product vs 1 guy who seems like he did something shady and got caught. Maybe it was an accident and maybe there is a way forward, but only if he brings to light the details of his actions.
Edit: Plus now you delete your post where you hint at your DDoS (by mistake or not) does not add up to your favor: http://i.imgur.com/1pxIxiN.png
One user sent me a bill for $10,000 after I cut 'em off for running a spam cannon, for lost business. I mean, I'd say 90% chance that they were just incompetent sysadmins trying to run wordpress and they got compromised, but ground truth was that they were sending out rather a lot of spam.
I sent a few notices before and after shutting them down, but their mail was hosted on the down VPS, so they never got it. Man, they were angry.
Dealing with stuff like this is the hardest part, I think, of running a low-cost (and thus low support expectation) VPS service. (one of the advantages, I think, of a high-touch service is that if you are paying me to manage your VPS, well, if it gets compromised, well, first it's my job to see to it that it doesn't get compromised, but if it does, it becomes my job to clean up the mess, bring up a new host, restore from pre-compromise backups, etc... - you get to be the hero rather than the bad guy.)
Key here, I think, is setting expectations; setting expectations is harder than you think, though. I've got a bunch of random copy on my front page... which is probably the wrong way to do it. But the customer needs to know ahead of time what is going to happen if they start spewing spam or participating in a DoS... and the customer needs to understand that they are going to get shut down even if it was an accident.
This problem is made oh so much worse by this massive influx of developers without sysadmin skills who should properly be on a more managed (or PAAS) solution who are moving to VPSs because they are so cheap.
Isn't this why most competent hosts request/require a secondary contact e-mail, not hosted by them?
Enforcing that requirement would be... non-trivial, though. I mean, I could look at the MX records for the domain in question, but those quite often don't point at the final delivery servers.
Still, I should at least make that a rule, even if I don't enforce it.
edit: Also note, even when you contact folks successfully, sometimes they refuse to deal with it, as, well, properly dealing with a compromise involves formatting and re-installing, then restoring from a backup taken before the thing was compromised. Most people at this level are unwilling to go through the effort, meaning that they will remain compromised for as long as you leave them on your system.
Often I'll setup a new domain for them, with the old domain read-only, so they can pick through the data. More than half the time, within 24 hours, they are compromised again.
"You might not get notified when shit hits the fan" seems like some natural enforcement :-P
Is that because they don't upgrade their software in response to being compromised?
Recovering from a competent compromise is... more complex than that. You pretty much have gotta read all the code you move from the old (compromised) system to the new system. As part of that, you want to minimize the code you move from the compromised to the new system; so you should re-install as much as you can from scratch, then move over your custom stuff, one file at a time, after reading it carefully.
If you have a good pre-compromise backup, and you have some idea of where the hole was and that hole was in one of the packages/support libraries, and that hole has been patched, then you can restore and upgrade.
As I'm running a no-support service, I'm not digging in deeply enough to tell you exactly what happened, but I believe that in most cases, users are just copying over their documentroot wholesale, and at best upgrading over the top of the (possibly compromised) copy, which quite often won't help you.
If they don't have a know-good local copy of the code to upgrade the stock components of and redeploy on a fresh VM that just sounds like asking for trouble.
What do you do with such customers? If you "fire" the repeat offenders would you say it's been worth the forum backlash from them (which this story seems like an attempt at so far)?