The comments and other answer already covered the PCI-DSS side of this, so I'll briefly address the JWT vs. (random) session token vs. OAuth side. As a side note, this is not generally what's considered "authentication mechanisms"; that would be things like passwords vs. magic links vs. biometrics vs. WebAuthN vs. client certificates vs. etc. OAuth and OpenID Connect (built on top of OAuth, which is actually focused on authorization) can also be used for delegating authentication to some other party, but if the other party is another system you control, you still need to decide how to do authentication there.
In any case, this question seems to be about authentication (or session) tokens, and by extension about session management.
Mostly, it comes down to what you need from your environment.
The advantages of JWTs is that they're scalable (no per-user server-side state needed, reduced database lookups), can carry user and session data within them in a trusted way, and that the issuer and verifier can be different systems (even with the issuer not trusting the verifier). As such, they're popular for highly-distributed systems, high-traffic systems, microservices, and anything with external SSO. The downsides of JWTs are that they're non-revocable (you'll want short lifetimes and thus either refresh tokens or very short sessions before reauthentication) and there's a "key to the kingdom" that, if leaked, can be used to generate arbitrary tokens that will validate successfully. As such, they are sometimes less preferred for very high-sensitivity systems that require precision control over session creation and duration and avoidance of single points of failure.
Random session tokens (stored in RAM, external cache, or DB) are arguably the most secure option, but they require synchronization/cache coherency, extra server resource/extra DB queries, and are generally not practical with any sort of federated or external authentication. They are generally best for simpler, smaller-scope projects, or for ones with very strong security requirements.
Both systems have security pitfalls (JWTs need to be validated correctly, random tokens need to be generated and stored correctly), but only JWTs have a catastrophic failure mode (exposure of the key) in a way that doesn't require fully compromising the server or the sessions table of the database. Indeed, random tokens can be made secure even against compromise of the sessions table (by hashing the client-stored token with an HMAC using a secret key stored outside the DB, and storing the MAC rather than the token in the DB). However, in many cases, the scalability of JWTs makes them the only viable choice; they are still quite secure if implemented correctly.
OAuth, by itself, doesn't really touch on either of these. In theory one could design an OAuth system that had to perform the OAuth flow every time any access-controlled operation was attempted, but in practice this would be intolerable to the user if the protected action(s) were at all frequent. Instead, upon completion of the OAuth flow, the user is typically issued a token of some sort. Most commonly, this is either a JWT + a random refresh token, or a random session token.