Nothing is perfect, including documentation, but support requests in the forum aren’t tracked, and GitHub issues are needed for that. For Duplicati, Issues shows its big backlog. duplicati-client is an independent project by a Duplicati developer, so the GitHub site you get it from has its own issue tracker that’s Issues.
Its home page, which I cited above explaining duc looks pretty reasonable to me, explaining the duc logic:
If one considers steps to be
1a. Windows self contained binary with path setup to call duplicati_client
or alternatively, for a different OS community
1b. GNU/Linux and macOS self contained binaries with option to create duc to not call duplicati_client
2. Usage which calls duc, made by recommended step in 1b just above, and 1a Windows users fail…
one might say that step 2 should backreference to the as-displayed prior step with sudo that Windows users skipped over, and to say that if one did not do the symlink in 1b, the usage is still duplicati_client.
To me, it’s not asking a huge amount to look one (skipped) step above or search in the page for a word.
Please flesh out documentation for installation & use on Linux was a similar case of different command calling depending on OS. On some, you need to say mono before the .exe’s name but examples did not. Interestingly, my Linux system knows what to do with a .exe that’s a .NET assembly so I don’t need that.
If you want to file a duplicati-client issue on README.md (which looks the same as the web site), text is:
## Windows self contained binary
For installation of the Windows self contained binary package I recommend copying it to `C:\Program Files\Duplicati Client` and then adding that path to your [environment variable path](https://www.computerhope.com/issues/ch000549.htm) so that you can call `duplicati_client` from anywhere in your CLI.
## GNU/Linux and macOS self contained binaries
Self contained binaries are also available for Linux and macOS.
These are useful if you cannot or will not install the 3rd party dependencies on your system, or if you experience compatibility problems with your current Python installation.
I recommend copying the binary package to `/opt/duplicati_client` on Linux and `/Applications/Duplicati Client` on macOS. Then symlink the duplicati_client binary
sudo ln -s /location/of/duplicati_client /usr/bin/duc
# Usage
To begin log into a server:
duc login https://my.duplicati.server
but I suspect the duplicati-client developer has more pressing issues either in duplicati-client or duplicati. Neither project is done yet. Both are in beta, so have room to improve, but there’s still priority to consider.
To be frank, after your quoting the “call duplicati_client” in your post here, me explaining the missed step here, and your still jumping directly to the (admittedly present with no caveats) Usage as seen here, you possibly will have continuing issues with Duplicati. It’s not the easiest thing to run, and sometimes gives problems even when run perfectly. Documentation may also use examples meant to be customized with individual values. The standard convention for such a hint (not just in Duplicati, but in many docs) is “my”.
https://my.duplicati.server therefore means [THE URL OF THE WEBGUI UNTIL THE NUMBER]. Clearly neither way of saying it can give the exact value, but the latter requires explaining what a URL is, while the former shows one. Either way, one could use lots of words explaining the intention for a target user base that needs that, but Duplicati is demanding, and needs more of users. Target audience issue.
A subtle point I see is that the left one is https, which has implications of getting that up. It’s a good setup for remote use over an untrusted network, but local users might use http. Another example of branching into an optional other area. Step-by-step fits single-path, but Duplicati’s flexibility gets in the way of that…
There’s more than one way to do it is a motto for the programming language Perl, but there are parallels with Duplicati and all its options and ways it can be used. In Perl, this tends to produce programs lookiing like what the author is used to, and other readers may have trouble. In Duplicati, it makes support hard…
Having only one OS, one storage type, and few options would be simpler, but some prefer more flexibility. Write once, run anywhere is from the programming language Java but also may be applied to .NET code. Its “Write Once, Debug Everywhere” developer joke also feels all-too-familiar in Duplicati environment. 
Documentation can be hard. I think one approach might be to give a step-by-step example as a warm-up exercise, explain it very deeply, then open up to the near-infinite number of variations one can actually do.
Anyone can file issues (and the more specific the better) but work rate is limited by amount of volunteers. Filing an actual GitHub pull request with changes you desire could possibly be picked up almost instantly.