The short version is that the creators of this API are doing something more secure than what the client wants to do.

A reasonable analogy would be trying to access a building locked by a biometric scanner vs. a guard looking for a piece of paper with a password on it. In the first case, only people entered into the scanner can get in (this is the cookie scenario). In the second case, anyone with a piece of paper with the right password on it will be let in (this is the Bearer token scenario).

More technical version: the API is made more secure because the "HttpOnly" cookie - which, basically, means the cookie's contents can't be read with JavaScript in the browser - is used to hold the credentials the server is looking for.

By allowing a third party to access the application, this means you have to allow methods that can be set "client-side" (e.g. via JavaScript in a browser). The most common method is in the "Authorization" HTTP Header - headers are metadata sent along with a request, they include things like the page you're coming from and cookies associated with the domain. A "Bearer" token is one of the methods specified by the "Authorization" header. It's usually implemented via passing the authorization credentials prefixed with the word "Bearer" (hence the name) and, often, are static, password-like text.

Basically, because this header has to be settable by a script, that means an attacker/hacker could possibly inject malicious code to steal the tokens because they must, at some point, be accessible.