This is certainly a good point. This consideration of dispatching is why we made it a first-class concern in Reactor. I'm not sure it's possible to do that here. The asynchronous behaviors can't be enforced or indicated by these abstractions, only the TCK could do that. But it's unlikely that a user would run their overrides through the TCK to ensure they meet the requirements. So there's certainly a valid reason to discourage their use.

That said, I think it's important for extensibility's sake to not get in a user's way if they want to take the responsibility of dispatching onto themselves by subclassing or implementing a base abstraction. It might be the only way to solve the problem in their domain. I think it should be clear, though, that if you take matters into your own hands and override the behavior in the implementation you're implicitly agreeing that such code might not be fully compliant and that you know what you're doing.

With great power comes great responsibility. ;)