Extensibility and access are two different design questions
A plugin or extension system built with functional extensibility as the primary goal tends to grant, by default, whatever access is easiest to implement — often the host application's own full access — rather than a deliberately scoped subset matched to what a typical extension actually needs. This isn't usually a conscious choice to trust every plugin fully; it's simply the path of least resistance when nobody explicitly designed a narrower boundary.
Plugin sandboxing corrects this by isolating what an extension can actually reach from what the host application itself can reach, requiring an explicit permission model rather than an implicit inheritance of the host's own access. A plugin that only needs to read one piece of configuration is scoped to exactly that, rather than incidentally gaining access to anything the host process happens to be able to touch.
Enforcement has to be real, not just documented
A permission model that exists only as documentation plugin authors are trusted to respect provides essentially no protection against a plugin that simply ignores it, whether through carelessness or malicious intent. The boundary has to be enforced by the host platform at runtime — genuinely preventing an extension from reaching beyond its granted scope — for the sandboxing to mean anything beyond a stated expectation.