I'm a bit familiar with Azure Queues and Azure functions and I'll try to provide some more context here. But short answer: Using Azure Queues here actually makes things less complicated.
An Azure function (or any function) doesn't do much in isolation. Someone has to call it, so you've got to figure out: who's calling this function, when are they calling it, and what context do they have at call-time?
General purpose functions allow a wide range of possibilities to the above questions, and it's a lot easier to shoot yourself in the foot. So many people implement their own queue-like functionality that Azure decided to abstract it away into a general purpose model that roughly says: This function is called whenever there are unprocessed items remaining in the queue, and only information that's in the queue is passed to the function.
When you buy into that model, you get a whole bunch of stuff done for you: They've added common functionality like retry logic, expiry of queue items, security/permissions/tokens and https endpoints, logging that provides visibility into failures.
It's eliminated a lot of boilerplate code and it's also an architectural model that's easily understood. I'm a big fan myself.
[also, disclaimer, I'm an MS employee, but I don't work for Azure]
I do think it does HTTP a disservice though - when you switch from HTTP to EDA you ditch the well known Uniform Interface and a lot of the benefits you get for free,(i.e. robust caching/proxying/routing, all the things a Service Mesh can do).
Instead of ditching HTTP, it would be nice to see people building async HTTP APIs, where the API responds with 201 Accepted (probably using a message queue behind the scenes) rather than the brittle systems you describe, where everything comes back under a 200.
"We used Azure Storage Queues to keep the whole flow asynchronous and more resilient to failures and load fluctuation."
That's not enough for me. I often encounter people building complex systems message queuing, despite failures being rare, retries being cheap and fast, and the hardware already being resilient to load.
In this article, a simple explanation of why each step actually _needs_ EDA/queues would be great - e.g. as the Product Matcher algorithm occasionally can't read a child's writing, an elf has to manually contact the child's parents to find out what they want so it can take a very long time.