Hi Julien,
Actually using request/reply pattern with messaging systems is pretty common and works well for this kind of scenarios. It is only the matter of an extra latency added because device read request is now send from end-client to LeshanServer through AMQP instead of calling it directly. However this kind of latency is usually really small, as your massaging infrastructure deployed in a data center or cloud is usually very fast. I've been working with customers using our messaging technologies for a while and honestly I don't recall a single situation when messaging request/replay latency was an issue.
As I understand with an architecture proposed by Kai we would have an end-client (like end-customer project willing to read device data) sending AMQP request/reply to Leshan wrapped as LWM2M protocol adapter. Adapter is able to receive the AMQP request, executes something like "leshanServer.send(client, new ReadRequest(resource))" and sends the AMQP response back to end-client. That would be really fast operation.
Keep also in mind that AMQP offers brokerless communication. With open source technologies like Apache Qpid Dispatch Router [1] you can connect two AMQP clients directly without the "broker middleman". That form of message exchange is extremely fast.
So I wouldn't be so concerned about using AMQP request/reply.
Cheers!