The fundamental problem here is signing keys as authoritative over subsets of a namespace (I believe). CAs are pretty good at that, so we should compare TUF to the CA system (with pinning). In practice, that means that you have to get a certificate for your package, which also requires a DNS name and SSL hosting. You could also use the PKI infrastructure, but only to sign the packages, and not require TLS. If you wanted to eliminate the cost requirements, you could offer subdomains of opam.ocaml.org, (and make sure that your CA would sign sub-sub-domains). But then you're taking on the burden of allocating those subdomains.
My fear is that even allocating subdomains of opam.ocaml.org is a tough problem in the real world. And you're not only doing (the equivalent of) that, you're also running an alternative CA, with alternative signing software. I wish you success, but this seems ambitious.
In contrast, we know the CA/https system works and we know its failings (in particular the evil CA attacks, mostly fixed by pinning). That system is highly distributed and needs no custom software. It also needs little extra work, which is always a good thing.
I've looked at the TUF papers. Can you elaborate on the attack you're describing? They don't seem to compare TUF to alternatives (that I could find). (Edit: and to be clear, my straw-man here is serving the initial git revision information over HTTPS, fetching the hashed data over HTTP & mirrors, and then verifying the hash)