I believe the audio quality degradation when using the mic is a limitation of Bluetooth bandwidth. It switches to a different profile capable of sending and receiving audio instead of only receiving.
Yes, it switches to a different audio codec, that’s unavoidable due to bandwidth limitations. However, macOS insists on using a worse codec than necessary (SCO instead of SBC) and, at least with my MX4 headphones, this badly scrambles audio, at least intermittently. I’ve stopped using the headphone microphone because it was unbearable. I’ve tried playing with the bluetooth settings but nothing seems to fix this.
It's definitely not an issue with bandwidth, instead it's an issue of standardization. There just doesn't exist a bluetooth profile that supports high quality duplex audio communications between two devices. It's pathetic.
There are vendor A2DP codecs that support duplex audio (faststream; aptx-ll optionally) but very few devices implement them. Software support is also fairly bad, although on Linux Pipewire does support them.
Also iirc CSR has a vendor codec (Auristream) in SCO transport that supposedly provides higher quality. Not sure how much better it is, or what software supports it.
So certainly better duplex quality is achievable. But there may be some licensing, hardware, or software support constraints that have prevented them from becoming more common.
I struggle to believe that Bluetooth 5, which supposedly allows for a total of 2mbit/s transfer can't allow for a better codec to be used when a stereo stream of SBC is about 300kb/s. However, I'll be the first to admit that bluetooth is not my area of expertise, and my statement here is mostly driven by disbelief about the fact that we can't get better audio quality out of a bluetooth headset these days.
EDIT: Oh wait, the reason HSP uses low bandwidth codecs is because the standard makes a trade-off in favor of latency and non-blocking comms. Clearly, there are good reasons.