Throughput drop and latency increase aren't solved by free certificates.
In throughput Netflix did a lot of work [1] to optimize HTTPS for their use case, and still went from 40 Gbps (network limited) to 10 Gbps (cpu limited). So they would need a 4x deployment to satisfy https everywhere to serve already encrypted files. This is probably not a big deal unless you're doing a pretty high volume of traffic, or have a really low powered server.
TLS setup adds at least one extra round trip to connection setup. This is a major latency penalty if you don't have servers close to your users. This is more likely to affect smaller sites/services, as geographic distribution comes at a signifigant cost (lots of servers + geodns/smart clients, or proxy through a cdn and lose end to end confidentiality)
Given that they own the whole stack, there would be value in statically encrypting content and serving that through an unencrypted channel, after having served the correct parameters through an authenticated-encrypted channel of course.
Basically, something like serving a torrent file through HTTPS and then using standard, unencrypted, full-speed bittorrent for sending the raw data.
Since the files are public, static encryption wouldn't do any good - the attacker could still build a database of hashes of all encrypted files, and then identify what you downloaded. What they really need is to sign the files, to avoid tampering.
TLS actually supports this, using a NULL cipher - you can make a regular HTTPS connection where the domain is verified and the data is protected from tampering, but everything is in clear-text. Alas, browsers don't support this configuration, since it's usually used by mistake or as an attack.
For 1. as I said the easy way is to distribute the torrent file through an authenticated, verified connection and then use that torrent file to get the raw data. Anything that doesn't hash to a piece in this torrent file is considered garbage.
For 2. that's an issue I didn't have in mind, and as long as the attacker can sign-in they can match an exchange with a database of hashes, so it's not protected in this regard.
In throughput Netflix did a lot of work [1] to optimize HTTPS for their use case, and still went from 40 Gbps (network limited) to 10 Gbps (cpu limited). So they would need a 4x deployment to satisfy https everywhere to serve already encrypted files. This is probably not a big deal unless you're doing a pretty high volume of traffic, or have a really low powered server.
TLS setup adds at least one extra round trip to connection setup. This is a major latency penalty if you don't have servers close to your users. This is more likely to affect smaller sites/services, as geographic distribution comes at a signifigant cost (lots of servers + geodns/smart clients, or proxy through a cdn and lose end to end confidentiality)
[1] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf