Not necessarily. To be honest, almost all arguments against forward error correction were against certain implementation decisions instead of problems with the actual method. Exceptions are arguments about the additional complexity it would bring.
For example, to address the complaint about low-end devices, FEC can be implemented in a way that the first 4 blocks of a 4-of-16 (or similar) scheme would contain the chunk unencoded, in an append-and-read way, so low-end devices would just need to request those first 4 blocks and “decode” them without computation overhead. With caching, this would not place high burden on the sections responsible for those blocks, and the storage cost would still be just 4x for a 13x redundancy. Higher-end devices could request a random selection of 5-6 out of the 16 blocks to achieve a much lower latency.
Anyway, this is a bit off-topic for this thread so I’ll stop here. (Thanks @draw for moving the posts.)