You say a dumb device is "good enough", but I would suggest that it will probably be easier to make a "smart" device that works well than a "dumb" device that works equally well. For a "dumb" device to work well, it's important that it faithfully capture all of the transitions on the incoming signal so that it can forward them precisely. For example, suppose that the protocol requires that there be no more than 20us deviation between the time an edge occurs and the time it's supposed to occur. If you use a "dumb" repeater, then the combined uncertainty of your device and the device it's sending to would have to be 20us or less. By contrast, if you use a "smart" repeater, then both links could tolerate 20us of uncertainty each.
Addendum
Reading some more about your specs, you don't seem to specify what sort of transmission delays are acceptable. It may be helpful to have a system whereby there is a designated 100ms spot during every five-second interval where a packet transmission must begin; units would exchange messages often enough to keep their clocks synchronized within 20ms. Depending upon what sort of compensated accuracy you can get with units' clocks, you may be able to do a very effective job of minimizing 'listening' time. Whether this is a good approach would depend upon how much delay you can tolerate in forwarding packets, and also how often you expect units to actually be transmitting data. A synchronized-listening approach would add 'idle' traffic, but would could reduce the number of times that packets have to be retransmitted.