Any reason NOT to set all cookies to use httponly and secure

Yes, there are cases where you don't want HTTP ONLY or SECURE.

If you need javascript to see the cookie value, then you remove the HTTP-Only flag. A couple cases - some sites track the page state in a cookie using javascript to read and write the cookie value. CSRF mitigations often rely on the server sending a value in a cookie, and expect javascript to read that value.

The Secure flag is more important. If we expect all sites to run over https, and only https, then the only http part is a redirect to https. You never want your cookie sent in the clear. Well, almost never. Here are two cases where you might:

1. development environments often don't have, or don't need to have TLS certs (though maybe they should).
2. to track activity that originated on http. You might even use your load balancer to set an insecure cookie before it sends back the redirect. Then your application analytics can track which URLs came in as HTTP. Your load balancer can track which sessions came in as http.

In practice, if you're running an https site, always set the secure cookie, and always error on the safe side by setting HTTPONLY, unless you know your javascript requires cookie access.

UPDATE - TLS in Development

A lot of talk about whether you should or shouldn't use TLS in development. Posted the question here:

Should I develop with TLS on or off?

Regarding httponly you are essentially asking if they are use cases where a cookie needs to be read or set by Javascript. Typically some settings of the user interface (choice of language ...) are preserved this way which would break if the cookie is httponly.

As for secure: since according to your description the site is using https all the time it does not harm to have all cookies secure.

Secure Flag

Considering that the application is running over HTTPS i.e. LB redirects all port 80 traffic to 443, it is still required to enable the secure flag in light of the following scenario.

1. Assume that there is a developmental glitch as a result of which a hyperlink contains the HTTP (eg. http://example.com/some_page.php) link instead of the HTTPS (eg. https://example.com/some_page.php) link.
2. The browser requests the web resource over HTTP and sends the cookie along with it due to the absence of the secure flag.
3. The request reaches the LB which redirects the traffic to port 443 i.e. over HTTPS.
4. The browser re-initiates the request but this time over HTTPS with the cookie value.

Hence, although the LB is configured to redirect port 80 insecure traffic to port 443 secure traffic, a successful MiTM attack could take place at step 2 resulting in the impersonation of a user by stealing the sensitive cookies. Moreover, verifying that the hyperlinks and redirects are properly coded is a comparatively more strenuous activity than enabling the secure flag on sensitive cookies. To conclude, although a redirect is set-up at the LB Level there could be possible scenarios where a fruitful MiTM could be executed due to the absence of the secure flag.

httponly Flag

This is a flag whose significance stays independent of the Transport Layer Security (SSL/TLS). The httponly flag is used to prevent javascript from accessing sensitive cookies like the session cookies in the event of a successful Cross-Site Scripting (XSS) Attack. When the httponly flag is not set on the cookie value, the malicious javascript injected into the application due to an application level flaw could end up sabotaging the confidentiality, integrity and availability of user accounts by reading session cookies and sending them to remote servers for instance, thereby successfully impersonating a legitimate user. Hence the httponly flag should always be set on all cookies or at least the sensitive ones.