I have now reproduced this behaviour on another system (Windows 7).
I also have more information about the issue. The Synology NAS is using OpenSSH 6.6p2. The 'hardware accelerated ciphers' are aes128-cbc, 3des-cbc, aes192-cbc and aes256-cbc, which are not in the list DOpus reports as available in the log error message. At present, it is therefore probably necessary for Synology users to disable this option. Doing so is not, however, sufficient to get DOpus to be connect. As of OpenSSH 6.7, CBC ciphers are disabled by default as unsafe anyway, so this is probably not a bad idea (at the expense of sub-optimal performance).
I have verified that the connection successfully established by WinSCP is using Diffie-Hellman group exchange, with hash SHA-256, and AES-256 SDCTR encryption. WinSCP negotiates SFTP version 3. The cipher seems to be the same as the aes256-ctr DOpus reports being available, so it is not at all clear why this is a problem. DOpus does not make clear what flavour of Diffie-Hillman key exchange it is using, but there is again no obvious sign that this should be problematic.
OpenSSH since 6.4 has apparently had curve25519-sha256@libssh.org as a default, but with a bug in 6.5 and 6.6 causing some such connections to fail; but that clearly has not prevented negotiating something else with WinSCP. Since OpenSSH 6.4, proprietary clients using 'a weaker key exchange hash calculation' have been rejected, and the size of the Diffie-Hellman groups requested have been increased. Perhaps this is something to do with it.
Is there any way to control the ciphers or key exchange mechanisms attempted by DOpus (in advanced preferences, registry settings, command line files, configuration files etc.)? What limits are imposed for KEX hash, group size etc.?