Which may be an issue in open-source, but not so much in a captive environment. When I clone an internal repo and run it on local, I myself don't do a security review of it. I trust rest of the people in company to have reviewed the code before committing to main branch. Company has the remote root access on the device it provided and we have internal binaries/scripts regularly used on laptops.

It doesn't need to be without user approval. I would be more than happy to email out a trustable commit hash or what have you.

Having an option to opt-out of some enforcement is somehow not much better than no enforcement at all.

How is this risk any different from that of a Makefile?

When one executes code from a Makefile, one expects arbitrary code execution. When cloning a repository, or updating a clone of a repository, one does not expect arbitrary code execution. Moreover, one can inspect a Makefile before running code from it, by cloning the repository and looking at the Makefile with a text editor; but one cannot inspect what will be cloned before cloning it (and even if you could, for instance by looking at it through a web interface, there's an obvious TOCTOU risk).

I see the problem with hooks that run when a repository is cloned. I don't see it with hooks that run when code is committed.

I might consider fixing a readme typo in somebody's project while taking less precautions than I would running make.