Practical differences between circuits and turing machines for cryptography
Just looking for a Turing machine vs circuit is a bit misleading. The important distinction is uniform (complexity class BPP) vs non-uniform (complexity class P/poly) adversaries. You can characterize P/poly in terms of circuit families, but also in terms of Turing machines with arbitrary "advice strings." In fact, the latter is the more traditional complexity-theoretic way to define P/poly. So just the fact that a definition mentions Turing machines doesn't mean it only applies for uniform adversaries.

If the authors are being careful, then their definitions will explicitly consider a TM adversary to take some advice string as input, and security must hold for all such inputs. Hence, security holds for P/poly adversaries. Even when the authors are not so careful with the definition, the results almost always carry over for non-uniform adversaries as well.

In general, I think it's safest to just assume non-uniform adversaries unless the paper explicitly says otherwise.



Of course, there are times when the distinction is important, and I can mention one way it might manifest itself. We generally have an asymmetry between wanting the "good guys" to be described by uniform algorithms, while protecting against "bad guys" who are non-uniform algorithms. Occasionally this becomes a problem when you want to convert an attack into a construction. For example, you can have a result like "an attack against scheme $X$ implies an improved construction for task $Y$." In these cases you often have to relax one of the definitions to bring them into alignment. For example, either:


"a [uniform] attack against scheme $X$ implies an improved construction for task $Y$."
"an attack against scheme $X$ implies an improved [non-uniform] construction for task $Y$."


Some examples:


Completeness for Symmetric Two-Party Functionalities - Revisited by Lindell, Omri, Zarosim: They show that certain protocols have some round at which Alice can distinguish some information about Bob's input. Then this distinguishing strategy can be used to construct an oblivious transfer protocol. But to incorporate this distinguishing strategy into another protocol, the strategy must be uniform, and the paper has to use a uniform definition of distinguishability. Alternatively, you could allow protocol constructions to be non-uniform.
In my own paper Universal Composability from Essentially Any Trusted Setup, I define a 2-player game between Alice &amp; Bob. If Alice has a winning strategy in this game, then I create a protocol of one kind. If Bob has a winning strategy, then I create a protocol of a different kind. But in both cases I need the "winning" party's strategy to be uniform (they are the person whose strategy gets incorporated into a protocol), while the "losing" party's strategy can be non-uniform (the losing party corresponds to the adversary in the protocol I construct). So the result leaves a gap (what if non-uniform strategies can always beat uniform strategies)? As above, you could close the gap by allowing protocol constructions to be non-uniform.