I think you are comparing apples and oranges. Providing the subsystem is not a client responsibility and API level is not protocol level (as in wire format) .
The question is if it's beneficial to decouple the client protocol from the core management API or not. But this doesn't mean clients have to provide the subsystem on their own. It's merely a design decision.
For instance when looking at the HTTP bridge for notifications, it might be beneficial to leverage a subsystem decoupled from the core management layer, that merely acts as an API client to the server internals. This way we might have websocket notifications as an early preview for example.
If we design it to be a part of the core management layer, then it probably depends on the availability of the undertow components. This is the degree of coupling we could avoid.
But I don't see all benefits & drawbacks of both approaches yet ...
We need to have one implementation at the api level, that all clients can use. Of course writing internal subsystems is über-cool,
but we should still consider people that want to write their client in e.g. perl.