It's pretty typical for mainstream keyboards to have keys that do media controls. With those keys, you can pause or resume a video or audio track, you can turn the volume up or down. You can also do a few other things, like launch a web browser or your email application.
One of things you cannot do is mute your microphone. Sure, there is typically a mute button, but on a computer it has a different meaning than it has on a telephone handset. On a telephone, muting means muting the microphone. On a PC, muting means muting the audio output from the speakers.
At first, this lack of keyboard code for muting the microphone seemed like a weird oversight to me. I thought maybe I just hadn't looked in the right place to find that keyboard code. Well, by now I have looked in the right places, and there simply isn't one. I don't know where they were originally defined, but those special keyboard codes are listed in HID Usage Tables FOR Universal Serial Bus (USB). Likewise, the Bluetooth HID profile builds mostly on the USB HID profile, so it has the same keys defined. In fact, the Bluetooth Human Interface Device Profile 1.1.1 simply references the USB usage tables.
All of that goes to show that it's not a mistake that keyboards don't have such keys, except maybe in special cases where the manufacturer has gone to some extra trouble (maybe on some laptops). Likewise, it's not a mistake that operating systems don't provide a driver to listen for such a code and mute the microphone. It's the same situation for turning the camera off and on. Instead, it's up to applications to control those devices while leaving management of the speakers to the operating system. OK, I still think it's an mistake, but it's a standards-based mistake.
The computer I use regularly for video meetings is a laptop provided by my day-job company. They are pretty serious about security, including supply chain security. So, even though I have reached the lofty level of Great Exalted Rhubarb in a software development organization, my laptop is pretty locked down. Any solution that required some kind of special driver could lead to an extra layer of hassle in going through an approval process to get it green-listed for my laptop. I have other things to do with my time (I was going to say better things, but I don't want to start an argument).
The laptop runs Windows. I'd hesitate to call that lucky, but one of the lucky things is that the very popular AutoHotKey utility is already approved for my use. Although that's a Windows-only application, I guess there are kinda-sorta equivalents for Mac and Linux. In a nutshell, AHK can intercept just about any keys that an infinite set of monkeys at typewriters could produce, and it can then take a scripted action. Scripting encompasses a pretty wild set of possible activities.
This mostly solves the PC-side software problem for me. If I can have a device that acts like a keyboard and produces keyboard codes that won't interfere with something else, I can have AHK intercept those keyboard codes and do the things I want to happen.
This flexibility also solves a user interface problem for me. What's the state of my microphone muting? If I simply use one keyboard code as a toggle, I don't really know if the microphone is currently muted or not. Instead, I can use one keyboard code for muting and a different keyboard code for unmuting. Contrast that with the standard keyboard code for muting the speaker. It's a simple toggle, which in practice is OK since you hear or don't hear the audio to know the state (or you are sitting in front of a screen that has some kind of visual feedback).