You could store the JWT in the db but you lose some of the benefits of a JWT. The JWT gives you the advantage of not needing to check the token in a db every time since you can just use cryptography to verify that the token is legitimate. If you have to look up the token in the db, you might as well just use an opaque token that doesn’t carry information with it and let the server and database provide you with the information. On the other hand, if you’re going to store a token in the db, I don’t think a JWT is a bad choice for your token type. As you say, there are advantages for revocation if you store your token in the db. It all depends on what you want to achieve (faster authorization, etc. vs ability to revoke on demand).
You can still use JWT with OAuth2 without storing tokens in the db if you want. JWTs have a configurable expiry time that you can set–after which they are invalid. Access Tokens (whether JWT or not) should usually be short-lived for security. If the concern is someone’s phone being stolen and access tokens being obtained, I think the solution is to have those tokens expire quickly (30 mins?). If you’re using oauth2, the means of stopping someone from continuing to use the app is for the real owner to de-authorize the mobile app client on the authorization server so that no more access tokens will be given out.