It's always interesting to hear real reports from the trenches that aren't essentially ads for technology XYZ. I'm afraid that all too often, we make things more complicated for bad reasons; whether ignorance, chasing the latest trend, or resume-driven-development...
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.
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".