No requirement for TRANSPORT security at all
The conditions of that contract can be satisfied by pre-encrypting the content, and using no link encryption at all. And that's what Netflix has been doing, in practice.
TLS is fine for remote browsing, where network latency can hide CPU load, but when you're sending the huge volumes of steady traffic that Netflix (or similar) does, the TLS overhead on each connection becomes very significant. Encryption is CPU-bound, and content servers have historically been configured with fast I/O, and enough CPU to do authorization and to make sure all the DMA pipes are kept full.
That said, although Netflix does not currently use HTTPS for content transport, it has completed a programme of infrastructure improvements that will allow it to roll out HTTPS in the very near future. (Overview here: http://arstechnica.com/security/2015/04/it-wasnt-easy-but-netflix-will-soon-use-https-to-secure-video-streams/ )