I have been meaning to respond to this for some time after seeing this question posed to Zooko on Twitter.
The execution layer tradeoff space for Celestia is an interesting one for enshrined snark verification. It seems as though minimization of state is a goal of Celestia L1 which means succinct proofs would be the best fit. Question is, just how “succinct” do you need them to be? This ranges from pairing based SNARKs which include Groth16 and KZG PCS (~200B) to non-pairing PCSs including IPA, Spartan, and other multivariate PCS (1-10KB) but probably not hash based schemes like FRI (10-100s of KB). To Zookos point, Groth requires per-circuit trusted setup, but this can be an application level decision to use it depending on just how specific the verification protocol is. KZG PCS enables succinct proofs for plonkish schemes with less trust (as it is an update-able, universal setup as opposed to Groth’s per circuit setup). So not all trust is created equal here, some of these ceremonies can be taken and built upon, making them quite robust (a powerful tradeoff for the succinctness they provide).
More applications will trend toward folding schemes as the tooling matures which adds additional verifier logic (hashing and verification over one curve for the primary proof and folding proof over a second curve). Doing this directly onchain is not going to be succinct enough. Compression proofs here will likely be commonplace for efficiency, becoming a proof like any other (with maybe a bit of extra, expensive to do in circuit, work).
All of this is defined over an Elliptic curve(s) (pairing based for pairing PCSs, dlog hard for non pairing based) which means it really comes down to popularity over usefulness for many. Being that BN254 is what ethereum supports with a lot of effort going into making tooling efficient for that curve and half cycles, that will likely be the best choice for many projects. I don’t know the cost of supporting many curves at the protocol level but that would be most beneficial as curve choice impacts the efficiency of the proving system for many applications.
In the end it really comes down the concrete limitations to be enforced on state growth, validator computational overhead and cost modeling and less about particular SNARK protocols as one, they are likely to continue to evolve (while being built upon the same low-level primitives) and two, different apps require different performance and trust.
This is a very interesting discussion that would blow up application complexity and whats possible to be built upon Celestia.