It's an engineering decision - Flikr has to host a large amount of data for very little cost, since most users aren't paying. Space isn't cheap by the Petabyte!
The design for a system where you had multiple redundant copies of all the data and could roll back any changes to the data set is different - and would cost a lot more.
Here is what I don't understand. They have multiple redundant copies in case of unlikely scenario of disaster, but they have no copies or protection in case of quite likely scenario of operator error. This seems backward to me.
EDIT: I don't believe that Yahoo! Flickr does not have a way to recover these things. Or I'm completely wrong.
I think it's likely that Flickr has a way to recover the data but the front line support personnel don't, and they don't want to have some dev spend a few hours to fix a single customer's problem, even if it was Flickr's mistake.
Reverting a full db should be straightforward (stop the db server and revert a dump).
For a single account it's more of a pita.
Retrieving all the datas associated with one account, put it in a format readable from the production environment and recommit all the changes while dealing with the potential errors and inconstencies seems quite a huge deal.
Messing unrelated data in the process would also be a nightmare.
Of course, not deleting anything from the start wouod be the way.
It's trivial in Oracle, just do a Flashback Query. You would just need to support that in whatever front end interface the customer support people use.
The design for a system where you had multiple redundant copies of all the data and could roll back any changes to the data set is different - and would cost a lot more.