Each Case will have a different threadId and the client will receive (if configured) two different auto-response emails. If the client wishes to add more comments to the case by replying to the auto-response, only one of the Cases will get the update. If you delete one of the two cases, you might be deleting the Case the client plans on responding to anew or the Case your service rep is already working on.
As such, even if you had an asynchronous APEX pattern (like Dan Appleman's) in place to delete one of the two Cases (the one that has no activity on it beyond inception), you might delete the Case the client thinks is the valid one.
Hence, such an asynchronous deletion pattern will need to re-inform the client of the 'true' Case - with explanation that duplicate Cases were errantly created.
Such asynchronous Apex pattern would run every minute (5 minutes) looking for stuff to do as driven by Appleman's custom Async_Request__c object (which corresponds to a new email-to-Case creation). You would look to see if there was a duplicate Case, figure out which of the two should be deleted, and notify the client with email alert of what happened.