Gustavo García wrote a blog post about this called Bandwidth Estimation in WebRTC (and the new Sender Side BWE).
To summarize: goog-remb and transport-cc are both congestion control mechanisms, goog-remb being an older method and transport-cc being a newer method.
My best guess is that firefox is stripping out transport-cc because firefox hasn't adopted the transport-cc changes yet. In my experience, Chrome is always ahead of Firefox in webrtc changes.
In a lossy network, these congestion control algorithms could tell the sender to lower the send bit rate. Lowering the send bitrate may reduce loss (at the expense of quality). However, if the network is always 10% lossy, like a noisy WiFi network, you still might suffer from video frame decode problems.
Handling video decode failures is a function of the vp8/h264 video encoding parameters, not of congestion control. As I said, congestion control might help reduce loss (in the event you are overwhelming your network with WebRTC packets), but if you just have a lossy network (e.g., poor wifi) the congestion control algorithms will just reduce quality without improving decode failures.