Certainly it is possible, but I think you’d have to step outside the “high-level” APIs. Of course, whenever you start using low-level, potentially unsupported/deprecated, APIs you have to consider whether you should even be using that type of addon.
Just what two things do you wish to communicate between? The chrome portion of the addons is just javascript and you can exchange information in any number of ways that don’t require special messaging. If you want to communicate between content and chrome then you have use (or at least ‘‘should’’ use) a messaging API.
It helps to understand the different types of “content” script that different types of addons use: WebExtensions use content scripts and has a number of APIs to communicate with chrome such as sendMessage/onMessage; SDK also has content scripts in a different scope and communicates with chrome using the port API; generic addons such as Jetpack and XUL overlays can inject scripts into content which then behave largely as page scripts. Different types of scipts in content usually can’t directly access each other using javascript (SDK content scripts injected into the same page with the same command can), but they can exchange information by methods such as custom events or the DOM postMessage API.
Any addon can also create frame scripts, which are in the content process and can directly access content objects but still have chrome privileges (with a few exceptions). They have their own inter-process messaging system. WebExtensions and SDK addons will have to require (chrome?) to do this. Prior to multi-process Firefox, and still when it is disabled, the chrome portion of an addon could directly access content objects and scripts simply using javascript. This can still be done from addons using shims, but is strongly discouraged because it is extremely slow when multiprocess Firefox is operating and may occasionally cause hangs or crashes.