Is this for security reason, or performance reason?
With --duplicate-cn, two connections with same common name are allowed, so one cert can be used by more than one connection/users.
Without --duplicate-cn, every vpn cert must have their own CN, so every connection/user have one unique cert.
It's actually neither of those reasons. If it had to be one of those two options, you might argue that it's security. However, using duplicate-cn alone does not make your VPN any less secure. There are two reasons that I know. The first is a concern about managing the credentials used to authenticate on the VPN--if many clients use the same certificate, then revoking that certificate also revokes access for all clients that use it, which may or may not be desirable. Also, it is common for a client device to roam and initiate connections from a range of public addresses--in those cases it is more likely desired for that device to retain the same address on the VPN despite the roaming, which requires there to be no more than one connection per client certificate.
A valid use case for duplicate-cn might be where your client devices do not roam and you don't care to control access on a client-by-client basis and your higher priority is not spending too much time managing keys and certificates. I believe the basis of their recommendation is the fact that such cases are in the minority and also that most people don't understand security, much less PKI-based security and they don't want to muddy the waters for such people.
I think the reason that duplicate-cn and client-config-dir together are not recommended is due to the problems that would arise if a specific user has a configuration with a static IP and they connect from multiple devices at the same time. Things aren't going to work well in that situation. As long as the multiple connection users don't have client-config-dir static IPs, there shouldn't be a problem.