Precisely. From my corner of the industry, my use case for flow data is extremely limited: I need (sampled) frame information: src-mac, dst-mac, qtag, ethernet protocol, framesize, sample rate. sFlow provides that in every sample, in a straighforward manner. (Never mind that the vendor we use does interesting things with the way they sample.)

IPFIX, by comparison, is a nightmare: to understand the data records, you need to have seen (and stored) the corresponding data template first. Those records will contain most of the information I need, *except* the sampling rate, which comes from an options data record... which you first have to match to an options template. Then, the sampling rate may not be present, but the sampling probability can be. Slightly different semantics. So that's four types of records your collector may receive. There is also at least one vendor that believes it's perfectly fine to export those over different transport sessions (read: different UDP source ports), which makes it really hard to do load balancing on the receiving side.

To top it off, both the sFlow and IPFIX specs are sufficiently vague about the meaning of the "frame size", so vendors can implement whatever they want (include/exclude padding, include/exclude FCS). This implies that you shouldn't trust these fields.