I think the most interesting DOS weakness in these rolling code protocols is that they are designed to resync even if the remote has a number of unreceived / out-of-range activations. This is a seemingly inevitable issue with a one-way protocol.
As I understand these protocols (per some manufacturer documents), the codes increment a counter with each activation. For security, no code can be used twice. (Thus, in a properly implemented rolling code setup, Flipper’s RAW mode will only get you a single activation.) The receivers will recognize a code that is ahead of the expected sequence number by a certain amount, say 10–20 steps (depending on design). So if your kid gets ahold of the remote and presses it a half-dozen times, it will still work without a manual resend. However, if the transmitter gets too far ahead of the base, the base will not recognize the code and a manual resync / re-enroll will be necessary. Crucially, the sequence numbers go only one way—up.
This is where the problem / weakness comes in: if the remote “somehow” gets behind the receiver, the remote entirely ceases to work until it catches up. The DOS weakness here, then, is that if you can receive and crack the code once with some of the special purpose software that does this, you can then advance the base station, say, 10 sequence codes at a time rather quickly. Once the base is 100 or so codes ahead of the remote, the remote is effectively disabled. (Unless you know exactly why it is not working and are patient enough to press the button 100 times…)
Is this practical? I don’t really know. But it does illustrate something interesting about rolling code systems: even a perfect clone isn’t very useful if your clone and original don’t somehow synchronize with one another.