Even if I was programming in a separate language, I'd still want a it embedded in a hosting type-theory so I can use it both for proofs and macros.
Has there ever been another non-trivial real-world program written in Coq (or another dependently-typed language for that matter) other than CompCert?
> Didn't know people actually used TLA.
Oh, far more than Coq; possibly more than Isabelle, even. TLA+ was designed for engineers, and evolved along with careful observation of how it is used by them. Coq is mainly used by type theoreticians to explore proving various mathematical theorems using ITT, and by PL people exploring various PL theories. TLA+ is used by engineers for large-scale software[1][2][3].
> I'd still want a it embedded in a hosting type-theory so I can use it both for proofs and macros.
I'm not sure what you mean by macros (I'm not a type-theory person in the least), but what does it matter if it's a type theory or a set theory? Lamport's thesis was that just as virtually all math proofs don't require type theory, neither do program proofs; indeed virtually none of the algorithm proofs in computer science employ type theory at all. TLA+ is a formalization of such proofs.
The main advantage of TLA+ is that it's as powerful as Coq for verifying algorithms (though it is not designed for proving general mathematical theorems), yet it any engineer can master it in weeks, without learning any new (not to speak of rather exotic) math. Also, it is amenable (and indeed supports) to model-checking, which alone is enough to make it practical. Deductive machine-checked proofs (which TLA+ also supports) are just too time consuming, and have ever been used on full programs only a handful of times. Their main use in industry is to tie together model-checked programs[4].
TLA+'s disadvantage is that it's very hard to extract a program from a TLA+ spec. Translations going the other way (from code to TLA+) have been done a number of times (for C and Java) but only in academia AFAIK. But this is unsurprising as Lamport's (and Dijkstra's) thesis is that effective, practical, program verification can only be done at a level higher than program code (unless it's a small program, specifically written in a simplified matter for the sake of verification, and the very large effort is acceptable -- all three conditions that have been met in the few cases where deductive, whole-program verification has ever been used).
[1]: http://research.microsoft.com/en-us/um/people/lamport/tla/fo...
[2]: http://tla2012.loria.fr/contributed/newcombe-slides.pdf
[3]: http://research.microsoft.com/en-us/um/people/lamport/pubs/h...
[4]: http://events.inf.ed.ac.uk/Milner2012/J_Harrison-html5-mp4.h...