No, it’s different: With --no-cache restic won’t use a cache, so everything (even tiny bits of data) are loaded directly from the backend. For a local repository that mostly won’t hurt performance, but for a remote repository using a new cache for each run will result in much better performance than --no-cache. Is that clearer? 
That’s not the case. Sometimes, data is used multiple times due to the way the deduplication algorithm works (e.g. a tree object that’s used several times in a backup), so that’s where the cache really helps. I’m not sure how common this situation in practice is, though, at least not for backup. For restore, I can imagine that there are many data blobs reused between files.
For backup the cache helps a lot for high-latency remote repository (such as B2), where it is quite expensive to fetch a file. Without a cache, restic will request parts of a file stored in the backend multiple times. With the cache, the whole file will be loaded on the first request, and then all future bits needed from that file are loaded from the local copy.
I think you’re right