In BBRv1 the PROBE_BW pacing gain schedule is purely based on the progression of time, and is orthogonal to (independent of) whether or not the sender is retransmitting packets.
The intuition for the rationale behind allowing bandwidth probing even with some amount of packet loss is that at high enough BDPs, and realistic/achievable loss rates, a connection must expect it can encounter packet loss on every round trip. For example, for a path with 10Gbps bottleneck bandwidth and a min_rtt of 100ms, the BDP is 10Gbps * 100ms / (1514bytes) = 82,562 packets. With a BDP that large, even a loss rate of 0.00125% means the flow should roughly expect around one packet lost per round trip, on average: .0000125 * 82,562 packet > 1 packet.
As far as details, the BBR article was brief, due to space limitations, but BBRv1 details can be seen in the Internet Draft:
And the Linux TCP BBR code:
Note that in BBRv2 the bandwidth probing does use the packet loss rate as a signal, and the connection will stop probing bandwidth if the loss rate goes above the loss rate threshold.
neal