You're right that the push semantics of Knative Eventing aren't really a great fit for your "broadcast to all nodes" use-case. I'd recommend using NATS (or some other broadcast tool, like Kafka without a consumer group or a watch API) directly for this use case; one reusable component which could be built would be a NATS-publish "sink" which transformed CloudEvents into natively published NATS messages.
To clarify a bit for the curious, Knative Eventing's model could probably best be described as "infrastructure-assisted competing consumers". This is a model that works well for the core use case of routing events between application components as a messaging bus (like in a FaaS), but there are other models that Eventing doesn't cover at the moment. A few high level patterns that Eventing doesn't currently cover:
Time-ordered partitioned data streams (stream processing)
State-tracking associated with object changes (workflows)
Backlog-focused event tracking (work queues)
All-instances state notification (broadcast)