Cryptography is complicated, so adding your own ideas can accidentaly make the cryptosystem more brittle. Don't do it if you don't know what you are doing (I wouldn't know either).
What a Public Key Infrastructure addresses is how to exchange keys. Briefly, there are web of trust based models to ensure the authenticity of a key, and there are certificate authority based models.
A cryptosystem is not going to get more secure by using a public key less. Either the system works or it doesn't. However, asymmetric encryption has two notable limitations:
It is computationally expensive. Therefore, most protocols that need to transfer large amounts of encrypted data use the public/private keys to negotiate a session key and then use that key with symmetric encryption for the remainder of the session. With current CPUs, symmetric encryption like AES is practically free.
A key that is trusted by others has to be kept safe. For example, you might not want to put a highly trusted private key on multiple servers. Instead, it can make sense to use set up your own Certificate Authority that can sign multiple short-lived keys. For example, you might use an internal CA to encrypt data flows within an intranet.
However, in a token validation use case (like JWT) these problems do not arise. In particular, the token is usually just signed, not encrypted, so no performance issues arise. Furthermore, a certificate might be significantly larger than a signed token, thus making it unattractive to create per-use public/private key pairs.
However, in JWT tokens cannot be invalidated once they are signed. The only way to expire tokens is to expire the key they were signed with. This means that keys used for signing tokens should be rotated/expired on a schedule, for example every week (this depends primarily on your business requirements). This also makes it necessary that everyone who wants to validate the tokens can automatically retrieve and verify the new public keys as well. It is possible to have multiple valid keys at the same time (in fact, there should be some overlap in their validity), but doing this excessively makes key management more challenging.