The bearer token can be a JWT, but can also be a different format of bearer token as long as it conforms to the requirements in the spec (ie, only certain characters are allowed).
A “bearer” token means whoever has the token has authorization to perform the action. (Section 1.2 of the RFC goes into more details.)
Most APIs just have you set a key in the "Authorization" header. I don't get what value the "Bearer " prefix adds.
That RFC is strange and seems it can be summarized in one line:
Include header "Authorization: Bearer [API key]" for authenticating API calls.
Not quite. username/password authenticate who or what something is; bearer tokens permit what actions can be taken by the holder of that token, and tend to be short-lived in nature and ideally for very specific actions.
For authentication & authorization, the caller sends a bearer token. The format of the token is known to both parties and the server knows how to validate it.
It's better than username password combos because (1) not every "account" has a password, (2) tokens can and generally do expire, (3) it's not tied to the password if the password changes the tokens continue to be valid, (4) the user can invalidate the tokens of their choice, (5) you can grant restricted permissions to a token. You can do more or less things with tokens based on the needs of the application but it decoupling it from password gives you additional security and flexibility.