An extension can use chrome.debugger API to get access to another extension but that requires explicit user consent and shows a warning at the top of all tabs in Chrome. The only way to do it covertly is to modify Chrome's command line i.e. add --silent-debugger-extension-api. Of course many users aren't tech-savvy so it's possible for an attacker to lull them into believing this warning can be ignored.
An extension can add a panel in devtools, so when the user opens devtools and switches to this panel, the panel's scripts can access the current page even if it belongs to another extension. It can run arbitrary code there and access/spoof its globals. There are useful extensions utilizing this e.g. Storage Area Explorer that allows inspecting chrome.storage of any extension.
A malicious web site can theoretically use a Spectre-based attack to break into the isolated world of the content script running in this web page and call chrome.runtime.sendMessage on its behalf, thus tricking the extension's background script to do something, see
this article in the documentation. You can probably guard against this by placing the entire code inside an IIFE where you would use a local copy of `chrome`, nuking the original one:
(() => { const {chrome} = self; delete self.chrome; ......... })()
As for breaking into the extension's background script process directly by a site or another extension, it should be impossible because normally extensions run each in its own process, unless the hacker found an unknown vulnerability in the browser that allows spoofing its IPC (inter-process communication). Note that if you have hundreds/thousands of extensions they will be grouped into shared processes.
If a hacker personally gained access to the physical computer or used a bug in OS that grants admin access rights to local files and running apps, there's simply no way to avoid exfiltration of non-encrypted data, the hacker would be able to do anything a local user can do.