It is usually regarded as a bad practice to use the same key for encryption and signatures, which means that one node (user, server, etc.) will have two keypairs: one to be used to sign content (the public key is used to verify) and one to decrypt content (the public key is used to encrypt). As a result, if you want fully authenticated and encrypted communication for two parties in this scenario, you will need 4 key pairs (two on each side of the communication).
Exporting the keys into .key files might be necessary in some scenarios due to compatibility, but it takes away the properties of a certificate and its legal binding power (since the key could be tampered without any straightforward way to notice).
After reading your comment, I'd focus on the point of each of the certificates. For that, suppose that you're the client of a bank. From your point of view, you might be interested in achieving authentication+integrity/confidentiality or both. For instance:
You get into their webpage to get the name of the phone number: you need to know that the number is right and belongs to them, and so it makes sense to expect the validate a signature associated with the webpage, so you don't get scammed. A server signature is needed
You send the bank an anonymous complaint: you only need to encrypt the message with the public key of the bank. An encryption to the server is needed
You want to login into your online banking and check information: you need to make sure that the information comes from the bank (signed) and that the information you send is only read by the bank (encrypted). You need both tasks.
Note that, at this point, no certificate or personal information has been given about you, as a client. You can use your own pair of certificates (in practice aided by a smart card, for instance), or, as in most cases, a weaker authentication method (password, password+one time password, etc.). In the latter case, a trusted session could be created with the mediation of only two certificates, both on the server side.
So, as you see, you can define schemes with 1, 2, 3 or 4 certificates, depending on the specific requirements and the availability of additional security controls. However, between servers the case with 4 certificates seems to be the more reasonable.