Cookies work when JavaScript is disabled or has failed to load (your basic functionality should work without it), localStorage doesn't. So unless we are talking about SPAs cookies are generally the better choice.

The sole reason really is that the contents of a HttpOnly cookie cannot be exfiltrated by an XSS-exploit, while a JWT stored in localStorage could be. This would probably only make a difference if the JWT either has a long lifetime, or is usable outside of the site's origin.

Other than the security implications of HttpOnly (and what it means for XSS), it's also convenience, and works well for small values you want to send with every request anyway, such as user session ids of logged in users and other forms of access tokens[0]. Your frontend code does not have to keep track of such values itself in localStorage (and maintain things like expiration) and it does not have to manually stuff it into each request itself, and so on.

localStorage and IndexedDB on the other hand are most useful for frontend only stuff that the server doesn't need to ever see, and for large chunks of data that you do not want to send with every request, and app-domain specific caches that would be awkward to implement using regular browser caches or ServiceWorkers.

[0] For example, cloudflare implements their "browser checks" anti-DDOS-protections by setting some token in a cookie so your browser isn't hit with that check page on every navigation (at least in theory, TOR users and a lot of VPN users have different experiences). Since the browser will automatically manage and maintain such a cookie, the actual websites behind cloudflare do not need any changes whatsoever to their code.

Cookies are sent with the first request, so the site can customize the response based on user ID. If the site uses local storage to identify the user , it will first have to send some bootstrap page which loads the id and sends it back. Much more cumbersome.

Doesn't local storage imply JS? How would you serve client with JS disabled?

As far as I know...

1. cookies can prevent js access (httpOnly flag)

2. cookies can enforce https only (Secure flag)

I think 1 is the only real argument.. 2 seems less and less relevant with HSTS.

I suppose the other thing you can do with cookies is use cookie prefixes. __Host probably makes no sense in the context of localStorage/sessionStorage anyway though, since they're all tied to the exact domain.

Having HttpOnly set only buys you so much, too. Sure, you can't steal the session from an XSS vector but your code can still do AJAX queries as the victim, potentially set up a JavaScript shell that works whilst the tab is open...

Local storage is per-origin, so anything set on an https page for a certain domain will not be readable on an http page and vice-versa.