This could as well be assigned to e.g. systemd or another basic configuration component.
The discussion of this topic is controversial and it doesn't look as if there would be a clean and easy to access solution anytime soon.
Corosync meanwhile has gone a slightly hacky approach for the same problem.
This it probably makes sense to target a similar implementation in sbd as well to first have a solution that doesn't require additional configuration and to be consistent within the cluster-suite.

Guess I've found a viable extension to the way how corosync is tackling the issue atm
that should be more compatible with the current behaviour especially in cases
where a setup has already introduced something like a realtime.slice that already
has some rt-budget assigned.
Configuration for it will reside in /etc/sysconfig/sbd:

## Type: yesno / auto
## Default: auto
#
# If CPUAccounting is enabled default is not to assign any RT-budget
# to the system.slice which prevents sbd from running RR-scheduled.
#
# One way to escape that issue is to move sbd-processes from the
# slice they were originally started to root-slice.
# Of course starting sbd in a certain slice might be intentional.
# Thus in auto-mode sbd will check if the slice has RT-budget assigned.
# If that is the case sbd will stay in that slice while it will
# be moved to root-slice otherwise.
SBD_MOVE_TO_ROOT_CGROUP=auto

As selinux-rules are quite fine-grained with sbd there are some
additions to the rules required:

For moving to root-slice sbd will need ro access to

- /sys/fs/cgroup/cpu/cpu.rt_runtime_us 

and write access to

- /sys/fs/cgroup/cpu/tasks.

For checks needed for the auto-mode additional ro access
is required for

- /proc/${pid}/cgroup

and

- /sys/fs/cgroup/cpu/${slice}/cpu.rt_runtime_us

https://github.com/ClusterLabs/sbd/pull/82

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3344