I want to address a few points just in case the crew consider this as a viable option for them:
I agree that The Tek becomes less relevant ( or, more accurately, less useful as information goes stale ) as time progresses, and agree that most people are likely not going to be storing old episodes of The Tek for nostalgia (me being an exception, because amusing and reasons (see The Tek 86: North of the Teeth of the World's intro...)). This isn't a strong reason though against a torrent option; most people would end up deleting the file or content after they were done with it (as I do once I'm done). Take for example BSDNow's podcast; they not only offer regular downloads of their video sessions, there are torrent options too (though the audio is not available as that type of option). Don't forget that even if The Tek doesn't benefit as much from such an option, there are other series by the crew that would (i.e. tutorials), cooking as mentioned above in the 1st post.
I also agree that bandwidth is costly ( as we well know, satanic cable companies... ). But streaming vs torrent? Data is data ( Phrases from Wendel(c)(r) ); either way, it's coming down the pipe eventually if you watch the episode in full ( seeking through is another matter ). A typical 1080p epsiode of The Tek fetched via JDownloader off of Youtube takes between 1.2 GB and 1.8 GB depending upon the length of the video. I'm sure that if the crew made their videos directly we might see an increase of 0.2 GB to 0.6 GB (+/- ~0.1GB ) because uploading to Youtube re-encodes the video that was already lossy encoded to begin with, as a trade with slightly better quality.
Now, I'm relatively sure that no sane or inexperienced person would host their website locally at their house ( there are exceptions ); more likely this is site is co-hosted at some data center or at least in Wendell's secret server lair, where bandwidth isn't exactly a problem. Such facilities have massive network infrastructure to handle the traffic. But let's assume the site isn't in a data center. I agree that it would be insane to expect 2TB of total upload bandwidth from one single system from such a connection. But that's exactly what BitTorrent was created to solve.
I'm going to use my connection as a frame of reference here, and again take your example of 50 to 100 peers on average taking the torrent option. Additionally, let's use 1.8GB as the average size of a Tek Episode. I have a 16Mb/1Mb ( ~2MB/~0.14MB) connection. Let's assume I have full utilization up and down. On average, it takes me ~15 min to get a Tek Episode using my current method. During that same time, I can contribute alone a paltry 126MB of data. That's ~14% of the total episode I contributed myself as opposed to the site doing it itself. A few people may stop seeding at this point. But many probably wont. They'll be too busy getting down and dirty with The Tek for the show's length of time ( around 30 to 45 minutes ). Again, assuming full utilization, that's another 252MB to 378MB contributed back; bumping the total percentage contributed back up to 28%. So the bandwidth problem here isn't as bad as you make it out to be.
The best valid argument I believe you have is:
Yes there are ways of encrypting and masking the nature of the traffic, but the people worried about ISPs taking it the wrong way, probably aren't tek savvy enough to know or figure out how to enable these features.
I don't see any counter-argument I can provide here for that.
Another valid argument against me would be that it's possible people may disable uploading, which would defeat the purpose of having a torrent option. It's likely though that many who actually use torrent won't do this for two reasons. Peers use a tit for tat system ( quid pro quo ); disabling uploading would cause some peers to ignore those people ( and have slower download speeds as a result ). Additionally, the super-seeding extension to BitTorrent mitigates harmful leeching behavior by allowing the main seeder ( the site ) to track whether previously seeded pieces were distributed to other peers it's connected to ( but at the expense of permanently choking the swarm when there is only one seeder and one leecher ). So they'll understand its value in this case. The other valid reason is that they're too unfamiliar to configure their client to do so.