Assuming we are talking about a common web app, the server can just set a cookie itself, which is a very transparent process: your frontend code don't need to read this token when authenticating, store it locally, and forwarding to each request than needs it manually. All things that could go wrong. The server will set it, and the browser will send it back as part of the headers for all your subsequent requests.

Until too long ago, this was also an issue, with csrf attacks that had to mitigated in some way, to be sure that any requests sent with the appropriate session id was actually legit, and not the result of some random site maliciously crafting post requests. With the samesite option, cookie are sent by the browser only after verifying the origin of the request.

From a security lens, cookies set with httponly aren't accessible via javascript. The typical alternative of storing tokens is the local storage, but as soon as an xss vulnerability happens, that token may be compromised.

You also typically want to avoid sending tokens as part of the querystring in your requests. While urls aren't visible in a normal https request in transit, your webserver of choice may log those request, in a file, that will contain sensitive information that shouldn't be there. They may be shared by user accidentally by copy/pasting the url as well.