Generally FEC would report corrected errors, so you'd be able to see if it's providing a value (e.g.
actually correcting anything vs added latency/CPU load).
Noting that TCP knows when frames have not been received and windowing of the frame. I would image that using a smaller TCP window size is the better option.
Idea with FEC might correct something to
prevent the TCP re-transmission dance. On a low latency fiber line, this would NOT help that much. But at moderate or high latency (& where latency is NOT due congestion)... any saving of TCP roundtrips dramatically lowers average latency, as the error-free latency on link goes up.
As for UDP( Voip / Gaming packet ), by the time FEC gets around to it, its probably not worth the processing time!
Agree, gaming may not be a good use case. And for PBX-style VoIP/video trunks, you can sometimes enable FEC on the RTP, which seems like a better place to enable FEC than a Mikrotik. But that is if the IP PBX support it...
It the UDP-based VPNs where overlying FEC may still be a good idea. Since more sophisticated UDP protocols still need roundtrips correct errors errors. And UDP protocols that's have no reliability, like SNMP... might also benefit to increase chance of a packet arrives intact and prevent gaps in SNMP data.
Not saying FEC is a panacea to lossy lines, but at minimum it give some data (e.g. are there FEC-correctable errors on a line?).