Why is "allow move on remote side" not recommended?

Why is "allow move on remote side" not recommended?
What are the possible problems that can (currently) occur when enabling this?
I need to know what the risks are before deciding if to use this option.

Thanks for the great program! Unfortunately i only get 11kcps with the host i connect to most of the time, but i assume the remote host to be the bottleneck.

Btw, as i read here in some posts ssh1 would be faster, is ssh1 less secure?

I've explained this in topic "Can't move from server to client with Drag & Drop + Shift" already.

Sorry, but no, you have not.

Move with drag&drop is disabled by default. You may enable it from Preferences dialog. However it is not recommended, you risk that you loose your data.

I had already read that post before posting mine, my question was "what are the possible problems that can (currently) occur when enabling this?" i.e. WHY is there a risk of losing data? give me an example if you like.

greetings

I believe I did :-)
You have quoted wrong part of the post. What should interest you is:

But if you drop it outside of WinSCP and target application fails to store dropped file, it can be lost.

First of all, you should note, that basic Windows drag&drop mechanics works in way that target application controls drag&drop. The source application does not know where the files are dropped.

OK, so example:
You move by drag&drop 100Mb file from WinSCP to Explorer (drive C: ). WinSCP does not know, where the file was dropped and Explorer does not know SCP/SFTP. My solution is that WinSCP pretends the file to be in temporary folder. When you drop file, the moment before Explorer starts to read file from the temp folder, WinSCP downloads the file there. This is also the last moment WinSCP has any control over drag&drop, so it is also the last moment it can delete file from remote folder (it is "move" operation). So it does it. After this, Explorer is finally allowed to start moving file from temp folder. It is long operation (100Mb file), so progress window (with cancel button) is displayed. Now imagine that either user clicks "cancel" or there is not enough space on target drive or any other problem occurs. The explorer fails to deliver file to target directory. The file is already deleted on remote host. If you're lucky, the file is still in temp folder at least. But it does not have to be.

Well, is it understandable?