Queues come from the following chain of reasoning:

BOB: I need to do X. I'm going to call the X-doing-service.

ALICE: What if the X-doing-service is down?

BOB: I'll use retries.

ALICE: What if the service is down for longer than your request timeout threshold?

BOB: I'll use a queue.

I don't really see a way out of this, TBH. Maintaining queues is easier than being a hardass about service uptimes. It also cuts down on request latency, because "I promise I'm going to do X" is faster than "I just did X and it totally worked".

Sure, sometimes you can just gracefully degrade and just not do X if you can't do X right now. Or, at least, it's not the end of the world. And sometimes you need X done right now and you can't wait. But message queues are a basic building block for a reason, and it's not an antipattern to use a lot of them any more than it's an antipattern to use a lot of pre-stressed concrete and rebar to build an office building.

In terms of how you build your message queues themselves, this is probably one of the best selling points for cloud services.