The section states that
If the local logout succeeded but some downstream logouts have failed, the RP MUST respond with HTTP 504 Gateway Timeout.
from my personal experience, lots of network intermediaries can easily override 5** errors and particularly, HTTP 504 (Gateway Timeout) status code. It isn’t uncommon to see all sorts of such network components between an RP and OP these days.
Furthermore, what’s maybe even more important, is that an RP say behind a K8S ingress controller could be literally unavailable or just overloaded. Thus, the controller has legitimate reasons to respond with 503 to backchannel_logout_uri as well as to any other endpoint on the RP side.
I suggest relying on a special status in the error and error_desciption parameters just like it happens in https://datatracker.ietf.org/doc/html/rfc6749#section-5.2 rather than relying on HTTP 504 to handle this situation. Otherwise, it seems to be very easy to “misinterpret“ obtained results or simply lose “Back-Channel Logout” requests.