So for SPA/frontend apps, you should be using PKCE these days for OAuth flow. But the backend apps have this additional complexity of having to have a secret key and use that key to talk to the token endpoint. Why not just use PKCE on the backend, too?
(This is a best guess as I am not a OAuth expert nor user).
RFC7636 created PKCE to incapacitate attackers with access to both client source code and relevant client communications. This is for example the case of some mobile applications which cannot ship secrets directly to the client device and cannot prevent other applications on the same device from sniffing the OAuth callback.
On most servers there isn't this kind of risk, as one can directly deploy secrets in a secure manner. On those servers PKCE would create unnecessary complexity. Complexity would both create new security risks and would divert resources which would be better spent mitigating more applicable security risks.
See also this YouTube video explaining the difference between confidential and public clients.
Having PKCE for confidential clients is a good idea. The draft for OAuth 2.1 requires PKCE for all clients.
In the summary the first bullet point reads:
PKCE is required for all OAuth clients using the authorization code flow
Having a confidential client is still relevant, as you can make sure, that only authenticated clients can get access tokens.
If you have a public client with PKCE an attacker can get access tokens from the Authorization server by impersonating a client. (In that case the attacker just needs to randomly create a code verifier and the corresponding challenge, then create an authorization request and handle the response and token request himself).