This presentation focused on work that's more recent. Improving the scoping story with let/const is one of the things that TC39 agreed on relatively early, though:
We gave up on TCP for => function syntax. I think Java reached the same conclusion.
It's really hard to retrofit TCP onto a C-like language with statements as well as expressions. At best you please only some programmers and confuse others, at a fairly high implementation cost (e.g., return from within a lambda called after its containing function deactivated).
Thanks, it's nice to hear it from the horse's mouth.
Does it make sense to think about TCP as being a matter of degree? Would it be correct to say that the number of constructs that would break TCP is fewer with let, const, and => than with earlier versions of ES?
I think a "partial TCP" would matter for manual refactoring, if not for (e.g.) a future macro system. On the other hand, perhaps it's more confusing to mention it if it's not total.
Saw dherman's comment just now, he and you are right that there is a spectrum of TCP, and if you use a subset of JS to write expression-bodied => functions, you get the refactoring property that people associate with TCP.
http://wiki.ecmascript.org/doku.php?id=harmony:let
http://wiki.ecmascript.org/doku.php?id=harmony:const
http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_...
Some of the new-function/lambda-syntax proposals even support Tennent's Correspondence Principle to some degree.