A PRP is Pseudo-Random Permutation and we want them to be indistinguishable from random permutations. AES and all block cipher are supposed to be PRP. The permutation means there is an inverse and they are designed to have one and indeed to have an efficient one.
We need a mode of operation for block ciphers and we left the CBC due to the many attacks that occurred though it has Ind-CPA secure. Currently, all of the TLS 1.3 ciphers internally use Ind-CPA secure CTR mode (TLS 1.3 cipher suites are more than that, they are all Authenticated Encryption modes with Authenticated Data)
Would such a relaxation gain us anything?
It gives us lots of opportunities. We don't need to restrict ourselves to PRPs in the CTR mode - it was already designed for Pseudo-Random Functions (PRF); CTR mode doesn't need the inverse of the function. With PRF we can use a wide range of functions that don't need to have inverses (There are $2^n!$ PRPs and $(2^n)^{2^n}$ PRF for n-bit block ciphers. Even we can take a hash function and convert it into CTR encryption as in Salsa. We may design a key schedule at almost zero cost, too.
Using PRP in CTR mode can cause the long message distinguisher and we can eliminate this by using a PRF. If we use PRP in CTR mode then we need to restrict the number of encryption blocks due to the PRP-PRF switching lemma.
CTR mode also doesn't require padding so they are immune to padding oracle attacks.
ChaCha20 and Salsa20 are well-known examples that have zero key schedule cost, ARX design with CPU friendly. They have built-in CTR mode and are very fast in software.