NIST SP800-108 KDF modes comparison According to NIST SP800-108, there are three modes that can build KDF from PRF: counter mode, feedback mode and double-pipeline iteration mode. Assume that the same PRF and input distribution are used, will the three different modes make any difference on security strength of the resulting KDF? Here the security strength aims at the unpredictability of the output and the threat model includes side-channel attacks. Thanks.
It is very likely that in practice this doesn't make much of a difference. I haven't seen any implementations in hardware devices of the more intricate modes (check the FIPS certification pages for info on this). Mostly the CTR mode is used, then the feedback mode. Many HSM's only implement one of the three, making all HSM's nicely incompatible to each other (thanks NIST for not indicating a default, even after being pointed out the problem!).

As indicated in the comments, these KDF's are build upon primitives which should already be protected against side channels. If unsure which primitive to choose, it would make sense to choose the one where the primitive is most resistant. In principle even a copy of bytes to another memory location (write!) can be vulnerable to side channel attacks. However generally speaking the KDF is secure if the underlying primitive is secure. It could be wise to go for a hash function if no hardware acceleration is available for a block cipher, as most hashes seem less vulnerable to side channels in software. On the other hand, the cipher may receive more attention to protect against them - without a specific system there is no strong recommendation can be made.

KDF's build from a PRF (instead of a hash) are relative strong constructions. So it may be that the double pipeline KDF is stronger than the other two, but basically the constructions are strong enough for any purpose anyway, so it makes some sense to choose the one that is easiest to implement. More complexity / a higher learning curve generally leads to a less secure system, after all.



Finally, as indicated, not every system implements all of the KDF's. It might be a good idea to look at the entire domain to see which implementations are available / secure / can be agreed upon with any other participants. Many systems won't have them at all, which again promotes simplicity over complexity. It's better to spend the time testing.