AES instruction sets implemented in hardware are the main factor in making HTTPS viable. But my toaster (which speaks HTTP), or my ARM based router, or even my high end server iDRAC/iLO does not have a dedicated x86 or AES hardware instruction.
so the point stands, even if it's not relevant to modern laptop users.
Google is already using ChaCha20-Poly1305 inside Chrome to talk to Google servers, if your hardware doesn't support AESNI. It's been doing this since early last year, and Adam reported at that time nearly 40% of all traffic to Google was going through it (including mobile devices IIRC): https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...
As for bulk data transfers for government-funded scientific research, data integrity for anything having to do with clinical trials or personally-identifiable information is among my highest concerns. And unless we're pumping that data across private fiber, the latency and bandwidth limits of the global Internet far outweigh the overhead caused by encryption/authentication algorithms.
(I would add that I think bulk data transfers ought to be encrypted over private/internal networks as well, but that's an argument for when I'm not on mobile.)
Not true. It's something like 30-40 cycles per byte to do AES without specialized instructions. That makes saturating 100mbit trivial, and saturating gigabit one of the easier problems. How much traffic can your toaster and router possibly be terminating?
Just as an example of the difference - I wrote a naive implementation of ChaCha20 in C with zero optimization effort and it does 5cpb out of the gate (Sandy Bridge). Just using vector-types and letting GCC/Clang vectorize brings that down to ~3cpb on Sandy Bridge - no effort. The Krovetz implementation of ChaCha20 is closer to 1.2cpb on my machine, with AES-256 doing 1.0cpb using AESNI (again, my own naive implementation). All software.
Even the most hand optimized, secure AES software implementations are still in the realm of ~15-20cpb (IIRC), three-to-four times worse than the unoptimized competitor. As linked elsewhere in this thread by me, non-scientific tests show it 3x faster in software on some mobile phones. That's a lot of extra cycles-per-byte for your battery to chew through using AES-256, and I'd guess I easily churn through a low number of gigs of HTTPS data every month..
And let's say you use 6-8GB of HTTPS data. 3 minutes of full use of a single 1GHz core per month is not a lot of battery.