> Even on an FS, you are more likely semantically switching off its visibility or its fd and not necessarily destroying the underlying bits. The resources are then collected and destroyed at a later and in batch, kept forever in a deactivated state, or written over.

So what? All of that is consistent with the semantics of HTTP's DELETE method. From RFC 2616:

  9.7 DELETE

    The DELETE method requests that the origin server delete 
    the resource identified by the Request-URI. This method 
    MAY be overridden by human intervention (or other means) 
    on the origin server. The client cannot be guaranteed 
    that the operation has been carried out, even if the 
    status code returned from the origin server indicates 
    that the action has been completed successfully. 
    However, the server SHOULD NOT indicate success unless, 
    at the time the response is given, it intends to delete 
    the resource or move it to an inaccessible location.

    A successful response SHOULD be 200 (OK) if the response 
    includes an entity describing the status, 202 (Accepted) 
    if the action has not yet been enacted, or 204 (No    
    Content) if the action has been enacted but the response 
    does not include an entity.
 

If you are going to say that the semantics of an HTTP method are not right for a particular scenario, there should be something in your description of the scenario that is inconsistent with the semantics of the HTTP method in question.

Sticking to the article -- not that I'm strictly suggesting DELETE is useless -- the extra verbs confuse the process. POST already covers DELETE, including the response codes. PUT is often more confused. And then PATCH. And then the rabbit hole. That is, DELETE can be semantically correct, but POST would be more so.

Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.

And perhaps I'm talking out of my ass, but the number of DELETE operations is likely vanishingly small for HTTP resources.

POST is not idempotent, DELETE is idempotent. That's a pretty significant difference. Yes, obviously, you can use POST in place of DELETE (heck, plenty of APIs have used GET in place of everything), but its not a good idea, and losing DELETE in favor of POST loses clarity.

> That is, DELETE can be semantically correct, but POST would be more so.

DELETE is both more specific about intent and more specific about the idempotence of the operation, so, no, POST would be less semantically correct for any operation where DELETE is semantically correct.

> Notice that, the quoted RFC does not state the resource is not inaccessible after the operation, only that it is intended to be.

Actually, it says that success (2xx) series codes should not be returned unless the server intends to complete the operation, and further specifies that that 200/204 codes indicate that it has enacted the operation (differing in whether a response body is included) and 202 indicates that it has accepted the request but not enacted the operation yet.

Idempotent methods are important; I'll give you that. However, the struggle between ACID and CAP theorems would suggest these are just words we will try to live by. I rather dislike having to imagine what it means for my DELETE operation to be bouncing around the network for a minute.

  > unless the server intends to complete the operation

A gerund; it intends to, without any guarantee of recency, to perform the operation. The very same problem that required the operation to be idempotent; it can't be guaranteed the operation is already done, only that it intends to complete in time. A 200 will only describe the status and does not require the description to be "deleted."