Some of these things are not like the others:

ActiveMQ / RabbitMQ / Apollo - "Traditional" message brokers. These provide AMQP, STOMP, MQTT etc. Safe choices for enterprisey dev. Think of them as standards-based infrastructure, like "web servers". There are good reasons to have various commercial and open-source options.

Theoretically (if you stick to core features), these are "plug and play". Most people really decide between them based on cultural factors. You might use IBM's broker because they're your preferred vendor or ActiveMQ because you're a Java shop and you prefer open-source. Maybe RabbitMQ because you because you like the community and so on.

ZeroMQ / nanomsg - Not a traditional "message broker", more like a "messaging construction kit". It supplies framing, patterns and some flow control, you build the rest.

Kafka - This is really "log as a service"[1], it just happens that you can also use it like a message broker. You'll probably structure your consumers as idempotent queue processors so you can get replayability.

[1] In the sense of transaction log.

Why do we need so many programming languages? Java, C++, Python, Scala, Elixir, Haskell, Clojure, Ruby

Why do we need so many browsers? Firefox, IE, Chrome, Safari, Opera

Why do we need so many laptop manufacturers? Apple, Dell, HP, Asus

As xyzzy123 mentioned, many of these message brokers have different feature sets and thus have different use cases. In general, most companies will pick a message broker based on 1) Their use-case needs 2)The support for the programming language and system environment (.net, linux, cloud). For instance if I'm moving terrabytes of data, I'm probably picking kafka.

Some message brokers are highly optimized for "at most once" delivery, where you want to receive the message between 0 and 1 times but you NEVER want to receive the message twice.

Others are optimized for "at least once" delivery where you MUST receive the message at least once, but you don't mind if you receive it more than once.

Additionally, different message brokers have varying levels of support for clustering, and varying responses to failure scenarios like network partions.

We don't. There's no central authority that makes message brokers; it's a group or individual who wants to make a new one that has some specific characteristic that isn't replicated elsewhere (anything from throughput and latency through language and creators).

Similar question: Why do we need so many JavaScript frameworks. Answer is the same: we don't.

As others have pointed out, it's competition.

This is why when you choose technology for a long term project you should consider whether it's still going to be around in 5 years, if not you might inadvertently become the maintainer.

We don't need them. Only 1-2 of these will actually survive.