In addition to Alex's use case of building on top of tools.build, there are other reasons a .jar can be useful.
Exact reproducibility is another reason to consider this. If someone wants to build a product used in avionics in the US, they'll need to be compliant with the FAA's DO-178C... I'm not a lawyer, but my understanding is one requirement is the ability to produce binary-exact duplicates of software deployed to a device for the lifetime of the device, that can be several years after they're approved. I don't do this kind of work myself, but I do things that support such folks. Minor changes to tools like clojure or tools.build can have effects on what exact code is produced/executed, how many instructions are performed, how much memory is allocated, etc. In situations like this, even the most minor backwards-compatible changes can't be tolerated. Other fields like robotics or satellites can have similar reproducibility requirements, and I suspect the US is not the only country with this kind of regulation.
A maven coordinate is a more-immutable thing, and has a better track record over the time to get you exactly-the-same artifacts.
Exact git commits are reliable (and probably a best option for most projects), but git histories can be revised or deleted... Git "releases" are even more mutable. They can be moved around (e.g. github to gitlab) and also tags can be moved. These are scarier ideas if you're trying to think 5 or 10 years in the future, where project maintainers may have changed a time or two.
