Anecdotal evidence suggests that certain kinds of workload (e.g., many clones of the same repository with slightly different options from build agents) may be achieving low SCM cache hit rates, due to the limit:

# The maximum number of upload-pack cache entries to retain _per repository_. If there are more than this configured
# limit, the least recently accessed entry will be invalidated.
plugin.bitbucket-scm-cache.upload-pack.maxCount=3

Now that SCM cache eviction (BSERV-9239) is managing the available disk space with a much more intelligent algorithm for selecting "cold" pack files to evict, we should be able to increase this value without any risk that it will cause instances' disks to fill up.