it is, when the limits are a bad thing.
Imagine if houses could only be built in the shape of a cube, because someone decided that the cube is the perfect shape for something else entirely.
HTTP has its place, REST has its place, messaging is a lot more than REST though.
It's always been, even before HTTP was invented.
Using REST for everything is the textbook example of if all you have is a hammer, everything looks like a nail
A lot of those failures won't even be detected, because you don't have proper monitoring, whereas in sync world you fail early and loudly.
And instead of "we had a downtime" you can sugarcoat it as "we had a processing delay". What's not to love?
You shall obviously set up monitoring of the MQ and all its DLQs. Once you've done that, you will literally never have a failing processing flow that isn't caught. A successfully initiated Mats Flow will either run to completion, or it will DLQ. Guaranteed.
The MatsBrokerMonitor is a Mats-specific such monitor (compared to the generic monitor ActiveMQ comes with). The pages here are a bit lacking, but it at least explains a bit: https://mats3.io/docs/matsbrokermonitor/
Proper monitoring typically requires application specific details and logic, which queues, being a dumb bus, typically don't have.
E.g. your client has a scheduled downtime every midnight, so you want your monitoring to not alert on messages produced by account X between 00:00 and 02:00. Oh, and ideally these exclusion rules are set up by non-technical folks (maybe even by customer himself).