There are two problems:
1. Totality doesn't guarantee that your program would actually terminate. A program that loops 2^100 times never terminates, yet is provably total. It is possible that empirically programs that are proven total turn out more likely to terminate, but in that case there is no need to enforce totality everywhere. You can prove termination whenever you like.
2. Proving totality can be extremely hard (yet another reason not to enforce it everywhere). So much so that Xavier Leroy, the world-expert who wrote CompCert, the only real-world, non-trivial program ever written in Coq, found termination proofs so difficult that he skipped them in CompCert, instead inserting a counter that he thought would suffice and throwing a runtime exception if it ever runs out before the function terminates.
As to total programming languages, safety-critical real-time software sometimes makes use of languages that are finite-state-machines, a far more restrictive model than Turner's total language. Nevertheless, bear in mind that even for FSMs, program verification is not generally tractable. How easy it is to verify a program depends almost entirely on one thing: how simple your algorithm is. All sorts of linguistic restrictions or safe runtimes can help prevent very important classes of bugs (like memory safety) that are local program properties, but do very little to make the cost of more global, logical properties affordable (which isn't surprising given that even the most restrictive computation model, the FSM, doesn't yield generally feasible verification).