... only because the typical http session is a few tens kilobytes.
When you want to stream gigabytes of data for each client, for millions of clients at a time, you are going to start caring about the overheads you create elsewhere in the pipeline.
The initiation of an HTTPS session is expensive because it consumes a large chunk of CPU for a real-world-measurable chunk of time, all at once, in most libraries.
Everything beyond that point you're dealing with <use algorithm of choice> over <max of 32kb> of data. It does indeed consume CPU. It does indeed consume perhaps 8x MORE memory than a typical http connection - but the memory side here is completely dominated by the fact that we're trying to cache multiple gigabytes of data.
You can serve HTTP faster than you can serve HTTPS with less CPU - this is objective fact. But if we're talking about CPU utilization? I can't speak to whether this argument has traction right now, for large connections, relative to the claimed 'non-problem' position of several companies who serve small sessions dominated by that connection time, but as time passes it's going to be even less coherent a position than it is right now.
