By "application security sandbox" - I'm assuming they mean from the file system
No, it's more complex. In most cases, if something is in the application security sandbox, it will get extra privileges that other content doesn't have. In this sandbox, AIR lets your app do special things that Flash Player in the browser can't do. Your AIR app's main SWF is in the application security sandbox because it is installed with your app. This seems to be an special exception where the runtime adds a restriction to your SWF in this sandbox instead of allowing extra capabilities.
See Adobe Flash Platform: Security sandboxes for details about the sandboxes, including the AIR application security sandbox.
It's possible that images that get installed with your AIR app might actually load in a flash.text.TextField because they'd be considered "inside" this sandbox. Someone else may be able to answer that. If you're loading from an external URL, though, they'll definitely be dropped.
My game is for both web and mobile.
If you can't get it to work in Flash Player in a web browser either, then it's not caused by this restriction to the AIR application security sandbox. It's something different.
Thinking about it for a moment more, I think I know what's going on. Starling draws a flash.text.TextField to BitmapData (and then uploads to a Texture) to display it. If the images aren't finished loading yet, then they won't be drawn to the Texture. There isn't an event or anything that indicates to ActionScript that the images have finished loading, so Starling won't be able to detect if it should wait to draw the TextField to the texture.
I'd go with StageWebView instead or maybe use a flash.text.TextField as a native overlay.