Unfortunately, yes. The await still means a blocking thread, except that other threads can resume doing other work. That is, if there actually is other work. For example, storing data in the database and sending data over the wire, are both RPC calls. Because usually a database is also an RPC call. Instead of waiting for a single call and then waiting for the second call, you wait for both calls at the same time. But both are blocking calls.
The .NET async/await is asynchronous execution versus messaging, which is asynchronous communication. Only with asynchronous communication there is no blocking thread.
With messaging request/response, there are two messages involved. So sending the request results in a message in the queue, but the sender continues doing whatever it should do. Responding to the message on the other side, again means a message in the queue. But the responding component can also continue work.
This can be used in two scenarios
Your website (or API) accepts a new order and instead of trying to submit it to the database (and potentially run into blocking calls) you submit it as a message on the queue. Your website (or API) can immediately resume accepting other requests. This is extremely useful on a website where the database or something else is the bottleneck. You can easily scale-out webservers, databases and so on not so easily. Or it takes huge amounts of money. If you’ve ever tried to order tickets or a product from a website and it was so slow you couldn’t order and lost an opportunity to purchase, it’s possible they don’t implemented their website using messaging. I’ve experienced this myself when ordering tickets for the Game of Thrones finale episode in a movie theater and created an entire presentation around it.
You want to show some data to an end-user and use messaging and request/response to retrieve the data. Don’t do this! Go into the database as fast as possible and return the data. Use messaging for background processing and storing data, not for retrieving it.