API Keys and JWTs embedding authorization are both examples of bearer tokens. The trust lies with the bearer of the token, both of them are subject to exposure and malicious use. Neither pattern is inherently safer than the other, but differ primarily in whether the information they represent is 1) verifiable by an external party and 2) require a call to a central agency to validate.
API Keys are opaque tokens. They are typically used for client-identification, since they are weak authentication and authorization models. You build rate-limiting policies around them, or use them to authorize access to an API at a client-by-client basis. If you need authentication data (a principal ID) or authorization data (scopes of access) you have to fetch them from a central authority.
JWTs can be used in a similar fashion. They also allow more sophisticated models by either signing (JWS) or encrypting a payload (JWE). With a JWS you provide the bearer and recipient crypographic proof that the contents haven't been changed since it was issued. With JWEs you can obfuscate information from external parties while allowing them to validate the token itself. They can be Base64 encoded and used the same as an API key, but if you have large payloads (lots of authorization data) you can exceed header sizes.
Both API Keys and JWTs need to handle revocation. Tokens that are exposed need to be removed from circulation. For API Keys the central host simply says the key isn't valid. For JWS/JWE you use the JTI to provide an invalidation list (similar to OCSP stapling or a cert revocation list).
The choice of which to use depends on your infrastructure, largely. If you're using an API Gateway, most will support an API Key model pretty easily. JWS/JWE models can allow those gateways to not call a central service, which is more performance. If you're building a microservice model, you certainly want to consider JWS/JWE - at least internally - as the app-to-authZ chatter can be very expensive.