I did some digging on this. That kernel flag is optional for Docker and only enables RT support in Docker if present. I actually tried quite a lot of things and was unable to get a sample Docker command to work with the RT feature (using the 5.11.22-180 kernel):
sudo docker run --rm --cpu-rt-runtime=940000 --ulimit rtprio=99 --cap-add=sys_nice hello-world docker: Error response from daemon: Your kernel does not support CPU real-time scheduler.
I tried the Docker daemon flags from the link your provided, as well as tried a few things from looking around for the issue. My guess is this is non-functional due to some breaking change in the kernel (as the /sys/fs/cgroup/cpu.rt_runtime_us file is missing which the Docker docs mention as a way to check for kernel support).
Also, I looked around and Debian, Ubuntu, Fedora, openSUSE, and Arch all have it unset (in their devel branches at least). Centos 8 is the only one I could find that has it enabled.
I think the benefits of allowing user-level pipewire/pulseaudio daemons to run in realtime mode outweigh the downsides of disabling a Docker feature that is most likely broken (and also unlikely to have many if any users).
Oh, I think I found it:
The cgroups v2 "cpu" controller and realtime threads As at Linux 4.19, the cgroups v2 cpu controller does not support control of realtime threads (specifically threads scheduled under any of the policies SCHED_FIFO, SCHED_RR, described SCHED_DEADLINE; see sched(7)). Therefore, the cpu controller can be enabled in the root cgroup only if all realtime threads are in the root cgroup
This is probably why it doesn't work with Docker and if so I see no downside to unsetting the config option.
Thanks. Makes sense that they dropped it with the cgroups v2 support. I have disabled this for our 5.12 kernel, which hopefully will get pushed out today if all my revdeps build against it.