Hi oneiros27, please take a look at the open issues and provide your feedback at https://github.com/WhiteHouse/...
The "additional CPU" nowadays for SSL is fairly trivial. If you've done some experiments that demonstrate a meaningful performance impact, and you can quantify the costs of that, we'd LOVE your feedback so that we can help you mitigate that or convince you that the benefits are worth the costs. We'd like to see data here.
Likewise with the caching issue. The use of CDNs can mitigate some of the performance impact you're worried about. If you're working with a specific scientific project or experiment where you need to shuttle around a lot of data, and are presently using HTTP and HTTP caching solutions to implement that, I would propose there are better ways of efficient data distribution. Again, submit an issue at the link above about this and someone can work with you to talk about your situation.
The IDS problem can be solved by moving the SSL termination to the other side of your IDS. It's not necessary for the origin server to serve HTTPS. It can also be resolved by changing your approach to IDS to one that doesn't require inspection of the payload at a distance from where it's served.
We do see privacy incidents routinely due to someone thinking "gosh, I didn't expect that would be private" or "I forgot to move that to the https site". We also routinely see ISPs and governments inject ads and tracking mechanisms into HTTP responses. We are also just simply concerned about the privacy and safety of people that browse government web sites and by standardizing on HTTPS everywhere, it eliminates the need for these mistakes and oversights and ensures a minimum bar for privacy and data integrity. It also makes it super easy to be FISMA compliant without having to spend extra to lock down a particular feature or product.
Please raise your concerns with the link given above and let's chat.