Since you can tell ORTC sender or receiver about the extension or not (i.e. activate the extension or not in that manner) it will effectively be unidirectional if you tell one side and not the other so I think it's still can be supported (and I agree, it's a bit overkill). The use cases to me maybe more if a personal wanted to indicate client-to-mixer in one direction only and mixer-to-client in the other direction only. Feels very SDP-ish and not needed in ORTC.
Agree that an application developer can provide the functionality of the "direction" parameter in RFC 5285 in the following way:
sendonly: Include the header extension only when calling sender.send(parameters).
recvonly: Include the header extension only when calling receiver.receive(parameters).
sendrecv: Include the header extension when calling sender.send(parameters) and receiver.receive(parameters).
inactive: Don't include the header extension when calling either sender.send(parameters) or receiver.receive(parameters).