By default, Contiki uses ContikiMAC radio duty cycling (RDC) protocol. The protocol has to deal with two conflicting requirements: allow receiver nodes to sleep almost all of the time when there are no packets to receive, but at the same time allow to deliver data as reliably as possible. The solution adopted in ContikiMAC is to place the burden on the transmitter. Given that receiver checks the radio channel 8 times per second (the default configuration on cc2538dk platform), the transmitter has to transmit for at least 125 ms duration to be sure that the receiver has waken up and seen the packet. In practice, this means that a packet is retransmitted for multiple times in row. See the ContikiMAC paper and Contiki documentation for more detailed description.
That being said, you won't always see transmissions with the maximum duration. If its an unicast, the receiver normally sends an ACK after successful reception. The transmitter checks for this ACK, and stops transmitting if received. This way, the expected average number of transmissions required is reduced two times. And then there's also Phase Optimization - it allows the sender to synchronize the start of transmission with the expected wakeup time of the receiver. But for broadcasts, no ACKs are generated and the phase optimization wont work.
Another possible reason for unexpectedly long transmissions is a failing CCA check. Before transmitting a packet, the radio stack first checks if the medium is free; if it's not, it will back up for some time and retry.
