I don't really agree... One reason is that computing models don't say anything useful about I/O, which we need in real computers. Turing machines have a strai

I don't really agree... One reason is that computing models don't say anything useful about I/O, which we need in real computers. Turing machines have a straightforward extension to incorporate I/O -- execute it as a side effect at a given step. In contrast, the Church model doesn't really have any notion of time, so it's not clear how to reason about I/O. What evaluation order is used? In terms of computation, they're of course equivalent, so you can execute the Church model on the Turing-like machines (or more specifically a Von Neumann architecture). So maybe that was the right "choice" (if there ever was one). There was an entire movement around dataflow processors AND dataflow languages in the 80's, where the instruction sets were not totally ordered (e.g. SISAL was single assignment). But these didn't fare well in the market. Closer to the ground, there is a pattern of "throwing away information at interfaces" in computing. Interfaces like x86, C, Unix, etc. get solidified by evolutionary forces. The cost of that modularity is global inefficiency. Another good example of that is the Java code gen architecture. People say "static types in Java code let you generated better code!" Well, no. The Java compiler throws out all the type information, generating Java byte code, which is dynamically typed. Then the JIT takes the byte code and has to re-infer all the type invariants to generate machine code.