From experience (the last time slides for a talk by Stephen Diehl made its way to the HN frontpage), there's a lot of information in the actual (recorded) talk that the slides are going to be missing.
There are a lot of advanced techniques in these slides, but if you care about program behaviour, in a functional context that mostly reduces to caring about the types of your functions. E.g., in Haskell if you have a function of type `a -> a` you know that it must be the identity function (leaving aside exceptions and undefined).
Taking this further, you can define functions of types that specify your desired behaviour exactly, e.g. guess what this does:
foo :: List a -> SortedList a
Or this:
bar :: VerificationToken -> Email Unverified -> Email Verified
That's really the main idea. If you specify the types in the right way, you can make them describe the function quite nicely.
People like to tout this idea about a lot, but I've never seen it used in any rigorous way. It's SUGGESTIVE of program behavior, but I haven't seen any tools for (attempted) extraction of even just FSMs from basic type-level state machines like that. You want to write down a property about "Email Verified" and the paths to values of that type and have the system check it. Real programs are too large for mere suggestion to have any assurance value.
... and I think this presentation had a lot more to offer than the absolute bog-standard techniques of labeled transition systems, whether you do it in the types or not.
I don't understand your points, I guess. Your first point is that you've never seen this technique used in any rigorous way, and your second point is that it's an absolute bog-standard technique? I don't follow.
Even if you never intend to use Haskell it’s well worth getting a basic understanding of it if you have an interest in CS theory just because it’s used so frequently in interesting talks and papers.
