Though a CA does not need the private key to issue a certificate, certificates for S/MIME will be used for encryption: once you have an S/MIME certificate, people will send encrypted emails to you, and the emails will remain encrypted in your mailbox.
This implies that losing your private key (e.g. your compute hard disk fails, or your laptop is stolen) entails losing your precious emails. This is a problem. To avoid that, encryption keys should have a backup (key escrow can be viewed as a kind of backup). In that sense, a CA generating the key pair and keeping a copy of the private key can be a very useful service.
Good CA ought to offer you the choice between generating the private key on your side, or on their side. If you generate the private key yourself, and never it to the CA (only the public key, as part of the certificate request), then any kind of backup is, of course, your responsibility.
Default mode of most CA is what is easiest to operate and makes the probability of an irate or distressed customer phoning them as low as possible. Certificate generation process will be mostly Web-based, but the certificate and its private key must in fine be available to the user's mail application, which may be quite disjoint from his Web browser. Sending a PKCS#12 (PFX) archive to the user as a file is a method which works "everywhere" (if a mail application supports S/MIME at all, then it supports importing a PKCS#12 file). Local private key generation, sending a certificate request, obtaining the certificate, and importing it back, restoring the logical link between private key and certificate, is a process which can work, but depends on the specific involved software (OS type, OS version, browser type, browser version, mail application type, mail application version). Many variants mean increased risk of helpdesk calls, which is the major cost in operating a professional CA.