There are two major issues with 24/7 logging approach
1. Amount of logs that we are going to received can be very high - eventually impacts storage space and need proper retention policy.
2. If underlying network design is not proper,chances are high it can choke the network.
My way of approach is
a)Logging should be enabled for rules that is very much required or enable it when situation demands
b) Ensure that you calculate the storage consumption during the peak usage of application for a given period of time and size it accordingly.
c) Filter/Drop/Rate limit the logs - you could do this at Source (IPFIX) or at any solutions that is in the path till the flow reaches the destination with same/different retention policies.
There is no correct answer here as environments differ a lot. I have setup NSX DFW IPFIX for quite a few customers and never got any perceivable impact, but this does not mean it cannot impact some environments. It is IPFIX, so some traffic will be added between each host and the IPFIX collector, but since IPFIX is not the actual traffic, this is usually not that relevant.
And this is different than logging that was mentioned. IPFIX is for knowing about flows going through the DFW and not for logging rules.
What are you using to collect IPFIX telemetry? For example, when using vRNI VMware observed up to ~5% overhead. From KB57894:
Q. What is the impact on ESX/Networking of enabling IPFIX on UPLINK ports?
A. We have been running IPFix at multiple customers without any issues. We have observed that until very high packet rates the performance impact on ESX is ~5%. The impact can depend on a lot of variables like number of sessions, rate of new session, length of sessions.
So I wouldn't be stressing too much about it.