It is not explicitly said nowhere in the specification, but I assume that encodings only make sense for media codecs. That is, for non-media codecs [CN,dtmf, RED and FEC] there is no sense of adding them in the encodings and will be used as follow:

-DTMF present in codecs only means that if can create a RTCDtmfSender for that sender and it will have the canInsertDTMF to true, and false if not present.
-RED will be used whenever an encoding has a fec.mechanishm of "red" or "red-ulpfec", and will not be used in an other case. It is ssrc-dependant so if an RTCRtpSender has two encodings with different ssrcs one with fec="red" and the other without it, it will only be used on the former one.
-FEC same as RED but on mechanishm = "red-ulpfec" or "flexfec".
-CN it will be used to send a comfort noise packets in case no voice is detected on track, on all ssrc streams.

RTX is a different kind and there are already other issues handling it.

So, I would recommend to add something like:

RTCRtpSender will ignore any encoding containing a codecPayloadType which references a non-media codec ("cn", "dtmf", "red", "rtx", or a forward error correction codec).