Related reading: https://support.cloudbees.com/hc/en-us/articles/115002991272-Why-is-my-multibranch-project-cloning-the-whole-repository-on-the-master-

Based on the Q&A section of the above page, you would still need space to store an initial clone the first time the job is run. Subsequent job runs would not pull all new changes though, only the new Jenkinsfile. Direct link:
https://support.cloudbees.com/hc/en-us/articles/115002991272-Why-is-my-multibranch-project-cloning-the-whole-repository-on-the-master-#whyismypipelinejobcloningtheentirerepositoryonthemasterevenwheniselectalightweightcheckout

Another solution to this would be to only use the Gerrit rest api when scanning for heads, and don't checkout any files onto master. I have a proof of concept for this which discovers changes on the server without a local checkout. This is similar to how the gitlab multibranch plugin works.

After reading though JENKINS-33273 it seems there are two checkouts happening that could be skipped. One when scanning for heads, and one when trying to read the Jenkinsfile and any script files in the repo. The first can be replaced entirely with the gerrit rest api, as that provides the current revisions of all branches, tags and changes. The second is a bit trickier, as it requires implementing SCMFileSystem. This could probably be done using the Gitiles rest api, but not sure how much work is involved there.