The problem with these busses is that each hand rolls its own security primitives and policies.
This sort of thing is better handled by the kernel, with filesystem device file permissions. As a bonus, you save context switching into the bus userspace process on the fast path. So, “the unix way” is simpler, faster and more secure.
File permissions are completely insufficient to achieve the kind of design that PipeWire is aiming for. None of the problems outlined in the article regarding PulseAudio (e.g. the ability of applications to interfere or snoop on each other, or requesting code being loaded into a shared address space that have unlimited access) can be easily handled with file permissions at all. The model is simply not expressive enough; no amount of hand-wringing about context switching will change that. This is one of the first things addressed in the article and it's very simple to see how file permissions aren't good enough to solve it.
That won't work here, the design of pipewire is to allow for things like a confirmation dialog appearing when an application tries to use the microphone or webcam, the application can then get temporary access to the device. That is a security policy that isn't really easy to do with filesystem device file permissions.
