chrome.storage.local is not localStorage. These are two different things. To use chrome.storage.local you'll have to do it in the caller (e.g. in the service worker) and send the data via
messaging. If it's huge you may want to migrate the data to IndexedDB (to avoid the potentially expensive step of serializing/deserializing), which can be used directly in the offscreen document (you'll also need "unlimitedStorage" in "permissions" in manifest.json to ensure it is preserved when the disk free space is low).
As for why, the offscreen document API is intentionally designed to expose just messaging. Otherwise extension developers would simply use it instead of the severely crippled service worker environment, which has a lot of deficiencies/limits that apply to web sites, but don't make any sense at all for extensions, which are installed locally. Regrettably, Chrome team still seems to genuinely believe they are "moving the platform forward" by switching to the service worker, even though even theoretically this is true only in 0.1% of cases or less (when the extension's main thread is blocked by a super heavy DOM for a long time), while 99.9% of time it's the opposite, the platform is moving backwards, breaking dozens of important features with no proper solution in sight, the offscreen document being a very expensive workaround, which degrades overall performance due to the need to create the separate JS environment and send the data over messaging.