Message-oriented stuff has been around a long time, so I don't think it's a fad.

It's basically taking the concept of "integration" (or API) itself and creating a product for it, just as a database is a product for the concept of persistence. Thus just as not every application has to reinvent a database, with a messaging product not every product has to reinvent queueing up integration calls if the target system isn't available.

The article also mentions request-reply being "what you really want", I think that this is a) not true, as a lot of the time you can fire and forget, and b) when you need it the products generally provide a request-reply API on top of their lower-level APIs. No need to reinvent.

I got the impression that the author didn't really want a message based system at all, but rather a request response system that they tried to impliment within a message broker. Of course that's going to create more headaches than it solves; it's the wrong solution.

Both message brokers and request-response code have their places in distributed systems, but they really need to learn when each is appropriate.

I agree, saying that request-reply is "what you really want" was kind of silly, especially after the opening paragraph that states "it depends".

Can you elucidate the differences between message-broker and request-response use cases in your eyes?

In my eyes (where the GP makes perfect sense), a message broker is asynchronous, there's no implicit wait while your consumers work on our request. A request-response interface will stop the producer until the consumer is done.