This is proposed in the past by Palant. See CrBugReport. He found several security vulnerabilities related to the less secure postMessage API in extensions. And concluded a drop-in replacement is a must have.

Extension content scripts will often use window.postMessage() for internal communication within a tab. This is almost always a security issue. On the one hand, this communication is visible to the website and might leak private information. On the other hand, it’s impossible to distinguish legitimate messages from those sent by the website. Examples of security issues this introduces:

• https://palant.info/2021/03/15/duckduckgo-privacy-essentials-vulnerabilities-insecure-communication-and-universal-xss/#another-case-of-ab-using-window-postmessage
• https://palant.info/2019/11/27/assorted-kaspersky-vulnerabilities/#uninstalling-any-browser-extension

No amount of educating extension developers about runtime.sendMessage() is going to help here. This alternative is just too complicated when you merely need to send a message to another frame in the same tab: you need code in the background page to forward your messages, and you need to somehow figure out the frame ID of the target frame. This is complicated and error-prone, so it is unsurprising that developers choose window.postMessage() given how it “just works.”

A simpler API could help here, even if it is merely JavaScript boilerplate wrapping runtime.sendMessage() – as long as extension developers don’t need to write that boilerplate code themselves. Something like this:

browser.runtime.onFrameMessage.addListener((message, senderWindow) => {
  if (message == "ping") {
    browser.runtime.sendFrameMessage(senderWindow, "pong");
  }
});

browser.runtime.sendFrameMessage(iframe.contentWindow, "ping");

The important properties here: communication isn’t visible to website or other extensions, incoming message are guaranteed to originate from content scripts of the same extension.