Support you have the following assets:

  - /js/foo.js
  - /css/bar.css
  - /img/baz.png

With a content-based hash, end up with something like the following:

  - /js/foo.abc123.js
  - /css/bar.def456.css
  - /img/baz.ghi789.png

This means that for each and every asset you have, you need to keep track of their unique filename for that deployment and you need to be able to access that whenever you want to refer to the asset. In practice that means most people rely on their bundler to rewrite every place they refer to those assets, which can make it awkward if they need to refer to them from non-JavaScript contexts. Also in practice, people often seem to ignore anything other than JavaScript or CSS, meaning you get stale assets if they aren’t JavaScript or CSS.

With a Git hash prefix, you would have something like:

  - /abcdef/js/foo.js
  - /abcdef/css/bar.css
  - /abcdef/img/baz.png

This means you only have one single reference to manage, which you can keep track of without relying on your JavaScript bundler. It also means that in a lot of contexts you don’t need the reference at all, for instance in your stylesheets you can just refer to url(../img/baz.png) and there’s no rewriting necessary to get the right behaviour.

Your build process and your infrastructure caching are two separate concerns; it’s easier if they aren’t tightly coupled.