Sorry this is not so clear. The motivation for this "is_risky" mechanism is to try to avoid having a BBRv2 flow knowingly hold the buffer at exactly full for a whole round trip time, when there is no need to do so.
The tricky part is that there is a one-round-trip delay between the moment a flow exercises a behavior that causes a buffer to overflow and cause loss, and the moment the flow detects that loss.
The inflight_hi value comes from the flow's previous measurements of the amount of data that most recently seemed like it would cause the loss rate to cross the loss_thresh threshold; so it's often right around the level at which the buffer is full and starts dropping packets. If a flow drives inflight up to inflight_hi and then waits a round trip time to find out whether this caused significant loss, then it's likely holding the buffer near the exactly-full point for a full round trip time, causing high delay and elevated loss for any other flows sharing the bottleneck.
The "is_risky" mechanism is designed to momentarily push inflight up to inflight_hi, then pull it down again until we can find out whether this caused loss. Once the flow sees that this bandwidth probing did not seem to cause excessive loss, the bandwidth probing continues persistently.
This may be more complexity that is warranted, and we may be able to shave it off before we transition out of "alpha". But that hopefully at least clarifies the motivation.