When a user attempts to resolve a file that doesn't exist in the Artifactory remote-cache repository, Artifactory will try to download this file and save/deploy it into the remote-cache first which it can only do if the user has the Deploy permission on the repository of interest. Only after the file is cached will Artifactory transmit the artifact back to the requesting entity/client (Maven, etc...). If the user doesn't have the Deploy permission, this operation will fail, and the file will not be cached.
Please note that granting a given user the Deploy permission on a remote-repository does not mean that the user can deploy artifacts directly into the repository cache. The Deploy permission on remote caches is used for caching artifacts from remote repositories only.
You can read more about Managing Permissions here.
The idea behind having to grant Deploy permissions to a user for the purpose of caching artifacts is to give you the added granularity of controlling which users can add files to your repository/server, versus just reading existing files on the server.
Even in the context of remote repositories, the word "Deploy" really serves the same purpose of "adding" or "uploading" new files to your server. Unlike a regular upload process, where you have a user uploading files to a local repository, with remote resolution the remote server cannot be identified as the uploading entity, so it makes perfect sense to correlate the operation to the user who requested the remote artifact.
A fairly common scenario is where the server Administrator allows a certain user to read existing repository content, but not add any new content to it (e.g new artifact version), in which case the corresponding user will have read permissions, but not Deploy permissions. This scenario would have not been made possible without this granularity in the permission model.
Imagine a scenario of an "irresponsible user" to whom you granted read permissions, who invoked a recursive download operation on a very large remote repository. Such a scenario can lead to serious performance and resource implications on your server (disk space, CPU, etc). In almost all use cases, such operations should not be allowed for every user.