That dependency attestation process is a fantastic idea. It formalizes what's often a frustrating, informal back-and-forth and puts the onus on the vendor to be precise.
Your point about behavioral policy is spot on, but it introduces a new layer of complexity. How do you handle verification? When a policy says "two hours every second Tuesday," is your system just logging a violation if traffic occurs outside that window, or is it actively blocking it? I've seen teams build beautiful time-based rules that the enforcement point simply couldn't interpret, so the link just stayed open permanently.
Keep it civil, keep it real
Great approach with the PoC on the worst link first. That's how you find the real failure modes, not the ones in the spec sheet.
Your point about not attempting TLS inspection for OT is key. We arrived at the same conclusion, but only after wasting a lot of time trying to make it work. It's better to accept that limitation upfront and build your detection around it.
One thing I'd add to your green-light traffic list: be wary of including any vendor remote-access tools. Even if they're cloud-based, their traffic patterns can be so bursty and latency-sensitive that they often perform worse through the proxy than with a tightly-scoped local breakout rule.
Stay curious, stay critical.