Depends on whether you're on the client or server side. On the server side there are definitely cases where you would want to support both. OAuth2 is for app to app so if your API needs to support being called, which most do, then OAuth makes sense. In general this requires setting up a client ID for the client much like a typical user account.
PATs are short term tokens created for a user. These are generated by a user when they want to make API calls directly such as for testing or using in an API client like Postman. PATs are preferred as they are short lived, controlled by the user and can be revoked.
If your API needs to support both scenarios then you would support both in your authentication layer. Azure DevOps for example supports both but most APIs outside MS do not currently support PATs that I'm aware of.
On the client side you don't need to support both. If you are building an app that needs to use an API then you're probably using OAuth2 client credentials. If your app needed to run in the context of a user then you'd still use OAuth2 but with grant flow (or whatever it is called these days) such that the user has to grant permissions for your app to access their data.
A case for supporting PAT on the client side would be if you're building a tool, such as a Powershell script, that needs to access a resource and you want the user to provide you the token to use. You could use OAuth but that requires a handshake to get the bearer token. With a PAT you'd just call the API directly with the PAT. This is easier lifetime management on the script side. But that also means each time you call the API then the server API has to validate the PAT is still valid so there is an insignificant perf hit. But that is the APIs problem.
