Why does Deja Dup use Nautilus for SSH? This leads to unexpected behavior.

I've been testing Deja Dup 18.1.1 on Ubuntu 1104 running in VirtualBox and it performs as expected with an attached hard drive and with Amazon S3.

In all cases, I set the destination folder to be VBoxUbuntu1104, just to keep things tidy.

When I tried using a NAS as an SSH destination, it kept failing with "unknown reason". Each time it would mount an SFTP volume on the desktop, rooted at my user folder on the NAS, but fail to write anything.

After much frustration I tried using my Mac as a destination. Much to my surprise, it created a folder named VBoxUbuntu1104 in the root folder and proceed to to backup there.

This explains why it failed with the NAS as a destination - I didn't give my user account read-write access to the root folder. I was then able to get it to work by specifying the absolute path to my home folder as part of the destination.

What I would expect:
1. If the destination isn't writable, display an error message.
2. Don't require an absolute path to the destination folder.

Observations:
When I run duplicity with an SSH URL as the destination at the command-line, I don't have to use the absolute path to the destination folder. On the contrary, a // is required after the host-name to force it to accept an absolute path, otherwise the path is relative to the home folder of the SSH user. I would expect Deja Dup to behave the same way.

EDIT (summary changed too)

It finally dawned on me (yeah, I know) that this behavior may be due to Deja Dup passing responsibility for SSH to Nautilus instead of to Duplicity - hence the appearance of the mount point on the desktop whenever Deja Dup is asked to use an SSH destination. Apparently the Nautilus SSH/SFTP feature connects to the root folder instead of (or as well as, confusingly) the home folder, which is either a known issue or intended behavior, depending on your point of view.

Is my understanding correct, and if so, why does Deja Dup do it this way? The obvious approach would be to use Duplicity's SSH support, for consistency and since it's there, but maybe there's some compelling reason not to do so.