Transfers differ from something like Invoices, Payments and Deposits in that there is no VOID or CANCELLED state; either the transfer exists AND was successful, or it does not exist. This kind of makes sense, as a transfer itself doesn't exist, and is only reflected either by a journal OR a Payment and Deposit.
However, there are restrictions on the deletion of transfers: If they are open, PreApproved, Overridden, or Approved, and in the case of send to bank, if the corresponding BI is at status NONE, REJECTED, PROCESSED, QUEUED, FAILED, CANCELLED.
This creates two gates to deletion that can conceivably fail. Workflow status should ALWAYS be correct, and any deviation there is indicative of a bug that needs addressing. Send to bank statuses are determined by a third party, and are thus PERMANENTLY prone to failure.
Any transfer in this condition will result in a call to support for resolution.
Instead, users should be given the option to proceed with the delete of these transfers. They can be warned that the status of the transaction does not show as open/complete, and presented with the option to delete anyway. We should track when these happen, possibly via logging, to show when possible issues have occurred, while still empowering users to work through this situation.