It didn't start out like that. Initially, it was just another WebSocket library with a focus on making it easier to scale to multiple processes.
It's kind of mind-bending to me though that it still feels like it's "too early." You'd think that the ability to efficiently process RPCs and pub/sub messages from clients whilst maintaining ordering would be critical... Yet if you look around the industry; callback-based event handlers are still the norm for most application logic and people are still not using queues where they should be. People think of queues as some expensive/bulky system with overhead which requires additional architecture (e.g. RabbitMQ, Kafka, STOMP, NSQ) and always requires exactly-once delivery, they have not tried to make the idea a core part of their application logic. Software today is FULL of race conditions because of this blind-spot. Yet I still cannot communicate my message. It's too difficult to explain the benefits.