As to why TLS 1.3 specifically, I recall early on asking for schemes that were more IoT friendly.
The consensus at the time was that encryption is important for ossification prevention and non-encryption was a deal breaker, as has been explained in this thread. However, there was nothing preventing other encryption schemes than TLS and this could be added in other later QUIC versions separately, but for QUIC 1.0, IoT would not be a priority in part to get something out of the door to finalize 1.0, and in part because TLS 1.3 allows for negotiation in case some encryption turns out weak. As to network transparency for troubleshooting, various tooling has been mentioned but there are header bits explicitly exposed to measure pacing and roundtrip of encrypted packets modulating a signal that can be observed, which was deemed sufficient after some testing, although there was a push for more insight operator side of things. QUIC load balancing protocol was also discussed, partly in order to avoid early TLS termination. LBs requires access to some confidential information in order to route packets correctly. I have not studied this closely, but I guess one could introduce a load balancer to gain more insights? Mikkel
