All those are valid topics that we are aware of already. Thunders were added (such as DataConsumer.send) to optimize things and the resulting API become hell.
DataConsumer.send() was added to allow the app to send a message just to that endpoint regardless that DataConsumer is connected to a DataProducer that is connected to many other DataConsumers.
DataProducer doesn’t have a “message” event because that would involve that every datachannel message received by the worker must be routed to Node (via the UnixSocket) channel just in case the app added an event listener in the Node layer. That would be bad for performance.
And in flatbuffers branch (so soon in v3) we have added “subchannels” to dynamically decide which DataConsumers should receive a message sent by DataProducer.send() in server side (see Next section in CHANGELOG in flatbuffers branch).
Summary: all this is gonna be reconsidered from scratch for v4 but we cannot break things in v3 or add more controversial API just to make it more symmetric.