At transport level, TCP only concerns with end-to-end retransmission of lost packets, and the customary acknowledgements needed to facilitate this. I would prefer to call this "error recovery" rather than control mechanism.
This end-to-end recovery only works well when the underlying network has a very low ratio of errors, and thus dropped packets. IIRC, the TCP/IP minimum requirements RFC requires that links provide a 1E-9 error discard rate or lower.
To that end, if a physical network link already features a packet error rate which is lower than 1E-9 or better, all it needs to do is validate the packet it receives from the wire and discard any packet that failed the validation due to a transition errors.
For links that do not perform as required, need to implement additional error recovery mechanisms, so that the error rate perceived by Layer 3 is compliant (otherwise, the error recovery initiated by transport will result in poor user experience).
To that end, wireless Ethernet (a.k.a. Wi-Fi) implements a combination of Forward-Error-Corretion (FEC) as well as a link-level retransmission mechanism.
Some of the newest wired Ethernet variants, e.g. the 10Gbps 10GbaseKR and all 25Gbps, 50Gbps, 100Gbps standards also implement a FEC layer, which at a cost of slightly reduced effective throughput, reduce the effective packet error rate to comply.
Fos historical accuracy I would also add that indeed X.25 (as well as Frame Relay) implemented a link-level (hope-to-hop) retransmission mechanism to facilitate error recovery, and the reason is that these protocols were designed to work on top of very long runs of unconditioned twisted pair copper wires, same ones designed and installed to carry 3.8KHz bandwidth of analogue voice, and would not exhibit a sufficiently low packet error rate without these link-level error recovery mechanisms. FEC would have been too costly (due to low base transmission rate).