There are and have been certification authorities that do provide key pair generation services. That should definitely not be the preferred way however. First of all, it allows the CA to act as the entity that has the private key, as they may have retained it $^1$. Secondly, it means that the transport of the private key must be secured. Finally, it may also make storage less secure; generally you don't want to have the value put in unsecured memory, which may also be swapped to a storage device.
Generally you would try and keep the private key as secure as possible. That basically means that the key value is only transferred if a backup is required. Sometimes simply requesting a new key should be preferred, but generating a new key pair means that the certificate needs to be replaced as well, and that could take too many resources (money, communication overhead, key management procedures etc.). Sometimes the key value may also be used by multiple related servers (e.g. for wildcard certificates).
Note that to request a certificate you only sign the certificate signing request or CSR using the private key. That allows for the private key to remain in a secure key store or (hardware) token such as a TPM or HSM, rather than be loaded into insecure memory.
One of the CA's that provided key pair generation services was DigiNotar. It was a notoriously insecure CA that went bankrupt after it was discovered that you could request certificates for any domain.
$^1$ although they could of course sign any invalid certificate request - in principle they would not need a request of a specific user; the process would be rather different though, and it should normally end up in the audit logging if they were going to sign their own requests