The answer ended up being yes. Duplicity modifies the atime of every single file's inode during the initial backup process. That triggers a copious amount of SSD re-writes and write amplification.
On subsequent (incremental) backups, a much smaller (but still substantial number) of inodes (and changed files, of course) are re-written.
Duplicity makes no attempt to preserve the atime of files.
To be fair, the way that Duplicity approaches this issue is quite conventional, and doesn't place a particularly large burden on HDDs. The issue of re-writes and write amplification is specifically a SSD-thing. So all that can be said about Duplicity is that it is not optimised for SSDs and that (all other things being equal) you'll wear out SSDs faster than HDDs if you use Duplicity.
As frostschutz noted in the comments, this issue can be addressed by mounting your filesystem with the noatime setting... so it can be mitigated relatively easily.
As HDDs go extinct, and SSDs take over, filesystems will increasingly be optimised for SSDs and we can expect the wear/performance issue caused by atime changes, re-writes and write amplification to be addressed. New filesystems like F2FS are leading by example.