It would be nice if these protocols could be easily decrypted using a key available on the client. Other than that, tough luck for the ‘transparent’ proxies and friends.
In principle it would be possible for the client to lack keys needed for the server to read data sent by the client, and vice versa, but in practice this is never done.
Under Forward Secrecy a Middlebox must learn fresh session keys for every connection or it can't decrypt it. Both clients (e.g. Firefox) and servers (e.g. using Java or OpenSSL) have facilities to dump the session keys out somewhere, and this is adequate for debugging although obviously you will need to acquire new skills if you're used to being able to get stuff done with a paperclip and a copy of tcpdump. At scale this get hard, arguably that's fine because a minute ago we said we wanted this for "debugging" but people who got their foot in the door with a "debugging" argument often actually want to decrypt everything, always, and so they're unhappy about this.
If you don't want Forward Secrecy you have two options. Firstly, when the specification says to think of a random number for the key exchange protocol, you can always pick the same number, or a number chosen in some predictable fashion, the Middlebox can know this number (or method for predicting it) and then it can snoop as normal. This works in TLS 1.3, obviously it weakens your security (if bad guys learn how to predict the numbers you are screwed) but that's your choice.
Secondly you could use a key exchange process that doesn't have any Forward Secrecy by design, such as the RSA key exchange from SSL that's grandfathered into TLS 1.0 through 1.2. In this case you just give the server's private RSA key to the middleboxes and they can decrypt everything.
As you may notice in all the above scenarios, this is very bad for your security. But if "debugging" is really the problem that's almost certainly acceptable to you.
1) Updates on every client you might want to debug
2) Securely transporting the session keys from those clients to the person debugging.
Those are some massive challenges. An alternative is to always MitM all your devices. This comes with obvious downsides. Moreover, I could see providers doing cert-pinning that isn't over-ridden by user installed certificates. That would make it literally impossible to MitM your own devices.
This kind of cert-pinning really scares me, because it takes away any possibility to inspect your own network communications.