I have posted about this before - but generally speaking, synchronous operations (for example, a user clicking a button and expecting some data back) are synchronous for a reason.
That is to say, synchronous - not because of the technology used to process their call - but because of a built-in and generally inflexible expectation on the part of the user that things should happen in real time and not "offline" (even if there is no material difference most of the time).
So, it's generally unwise to put any kind of offline or asynchronous technology stack in between a user and their expected response.
As with all things, exceptions abound (and could spawn a whole new conversation), but certain types of user calls can and should be handled "off-line" depending on the situation.
However, I do feel that the focus of your assertion:
I like the idea of using messaging to decouple the clients from the services
misses the point somewhat. We don't actually want to decouple clients (or consumers) and services.
We would expect a client for, say, the Accounts Payable business capability to be highly coupled to the accounts payable microservice.
Similarly we would expect a high degree of coupling between a service endpoint signature bool ProcessTransaction(Transaction transaction)
and the consumer of such an operation.
Where decoupling becomes really important is decoupling between services which support different business capabilities.
And it's here that the benefits of messaging really make a difference. Let me know what you think and if this has helped you at all.