Just a couple of thoughts from me.
The job of the IoT Connector is to provide the nice programming model for the IoT use cases (telemetry, provisioning, etc.) for a heterogenous (and large) devices environment. So, in my view this is something that needs to be defined on the northbound of the connector. People tend to prefer reactive/asynchronous APIs these days, but if there’s a need, the synchronous style API can be created as well (at least for certain cases). Then connector needs to translate that to whatever protocol/semantics devices use. And that’s the job of Protocol Adapters. So the adapter is just a one piece in the whole picture and it’s not where we should be solving “application developer” view of the system.
In my opinion, the messaging is a good fit for this intermediate layer, as it provides many benefits, like decoupling, flexibility in terms of scalability, routing, security, etc.
TLDR version; I agree that we need to provide an easy and natural model for developers using IoT Connector. We should do that with a proper design of API(s) on the northbound. The job of the connector and adapters then is to translate that API to the real world of various devices and gateways.