Yes, you are right.
It's implemented the way it is, as it was way easier.

I have added this issue to the tracker:
Issue 2424 – Full Windows shell data transfer support
You can vote for it there.

Yes, overwrite confirmation was disabled, but that's not the point. In any case, these confirmations are opened in the background and can be overlapped by the target app.
According to clipboard transfer scenarios, source app is responsible for the source object prepare, delete-on-paste and cleanup. Main operation should be performed by the target app.
Why not to use FileGroupDescriptor format that is designed for virtual file objects? Or prepare real file object instead of a fake directory?

Overwrite confirmation is shown by default, unless you have disabled it:
https://winscp.net/eng/docs/ui_pref_environment

Otherwise you are correct.

As far as I understand, copy to the clipboard from FTP listing is done as follows:

1. Hidden directory is created in temp directory, like: C:\Users\<user>\AppData\Local\Temp\scp57345
   
2. ReadDirectoryChangesW monitors are installed on all local drives with subtree watch.
   
3. HDROP format with hidden directory path is placed on the clipboard.
   
4. When directory with the same name as hidden directory is created on any local drive, it is removed and replaced with the object that should be copied.
   

Issues:

1. If target directory already contains item with the source item name, WinSCP silently replaces it. In type mismatch cases (file<->folder) WinSCP displays confirmation.
   Target application should perform copy operation, not the source app. Source app should prepare source object and perform the cleanup. Target should be able to check object existence and display confirmation, but in current implementation it can't, because HDROP contains temporary name.
   
2. If a directory with the same temporary name will be created somewhere on the local disks, but not as part of this clipboard operation, it will be replaced with the source object.
   

WinSCP 6.5.5 (Build 16453)