Arguably this could avoid the `$CI_MERGE_REQUEST_DIFF_BASE_SHA` suffix for the cache key, which would make the cache persist across different rebases and MRs.
With the suffix we can be sure that when the Gitlab cache is hit, the ccache is going to be quite close, and rebuild will be quick. However it will hit less often and only if an MR has previously been built against the same base commit.
Without the suffix the Gitlab cache will hit more often, but possibly with completely unrelated objects in the ccache, and the last MR being built will update the ccache with its objects, regardless of whether they are based on recent code or not.
Depending on the ccache size, it may be worth not using it, idk.