Allowing extra usage types can go anywhere from not mattering to being a critical security breach, depending on what parts of your infrastructure trust certificates from that particular certificate authority.
As an extreme example, if a certificate has the CA flag (which is in a basicConstraints extension, not in the keyUsage extension) set to true, then the holder of the private key can sign other certificates and thus can claim arbitrary identities. As another example, on a middle-tier server which is itself the client of an end-server, you might care about separating the client roles and the server roles, so that the middle server has one certificate with a clientAuthentication extended key usage and another certificate for a different key with a serverAuthentication extended key usage. Or if the same CA delivers both TLS authentication certificates and code signing certificates, being able to claim an identity shouldn't allow signing code and vice versa.
On the other hand, allowing an extra usage that nobody will care about is harmless. If none of the software you (or anyone who might trust this certificate) run would ever check whether a particular usage is allowed, then it doesn't matter whether this usage is allowed. For example, if nobody is trusting that particular CA for code signing, then it doesn't matter if the extended key usage extension is not present or contains the codeSigning flag, even if the certificate was only intended for TLS authentication.
Allowing dataEncipherment is very likely to fall into the harmless category since decrypting data with a private key is very uncommon. It's unlikely that you're running any software that would check whether a certificate allows data encipherment.
Allowing extra usage types has no impact on performance.