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:
- development environments often don‘t have, or don‘t need to have TLS certs (though maybe they should).
- 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: