I am actually -1 on this idea. They should be able to afford terminating SSL on the load balancer end. It doesn't change the architecture for as long as the load balancer terminates the traffic. Securing HTTPS internally is an expensive move. CPU wise has always been an argument (or more like an excuse). If your load balancer is doing computation other than forwarding requests and decryption SSL session, you should double check your architecture. If small startup will millions of views can sustain SSL traffic, why not NYT? Most their traffics are just serving static files and results are usually cached anyway.

Instead, the burdens are on testing and developing the migration. For example, they'd have to inventory and edit everywhere they use http:// (hardcoding the scheme in your front-end code) instead of //. Furthermore they have to support third-party ad networks deliver active scripts (like javascript) over HTTP. Having HTTP while on HTTPS will create mixed content warning and for active contents browsers will block these violations immediately, thus breaking the website.

To me, the decision of not migrating to HTTPS because of infrastructure capacity is always a myth. Someone has to prove that with data.

Can I ask you why you say it would be too high for NYT to afford it, when many companies with significantly more traffic have site-wide TLS?

The most commonly cited answer I've seen for these kind of questions hasn't been the cost of serving HTTPS but rather the delays in getting the ad networks to support HTTPS. Some sites reported that they had fewer bids (and thus lower revenue) for ads on HTTPS pages, which is something I'm sure the NYT management watches very closely.