Yes they are!

I think I know the reason: OAuth2 naming. In the OAuth rfc https://www.rfc-editor.org/rfc/rfc6749 they named one of the role "client", but than meant to represent a server in the more standard flow, while they named the browser "user-agent". Then people understood that "client" is the browser, so they went nuts storing access token and refresh token in the browser local storage, instead of being store in the server session storage, accessible with a session cookie.

So what people should have done https://www.rfc-editor.org/rfc/rfc6749#section-4.1 (you can see here the tokens never reach the user agent, so the server can keep them in a session, then have the user agent identified by a cookie. And what most of the people did https://www.rfc-editor.org/rfc/rfc6749#section-4.2

This is a very useful piece of information.

According to the saying "There are two hard problems in Computer Science: naming things and cache invalidation"...

OAuth 2.0 editors failed to properly name things.

But there are many times when the client _is_ the browser. Are you sure you're not confused by that?

In the RFC, the browser is named "user-agent". And in OAuth2 flow, the browser is acting as client only on the implicit flow. Also the intent of the authors for the implicit flow is that the "client" is a mobile/desktop applications, and not especially something running in a browser

Yes, but I think there are plenty of OAuth2 libraries/clients implemented in ts/js to be used directly from a web application. A JavaScript client running in a web-page still presents itself to the OAuth2 server as the regular "User-Agent" that's used for the web/HTML parts of the interaction unless the requests being done are enhanced with a custom header.

For these clients saving the tokens in the local browser storage is the more elegant option in my opinion, to saving them in a cookie and thus polluting the rest of the browser's requests to that same host.