Consider these two scenarios:
a) Someone using your component must also understand your component's full stylesheet and must determine (through analysis or through your naming conventions) what she can safely change about your component's styling, vs which parts are likely to be changed by you (or completely refactored) in future versions.
b) Someone using your component gets an API for the things they should be able to change about your component. The rest of your component can be updated (and its implementation changed) as you see fit, and as long as the consumer has followed your public API, the new version will work.
I think that with scenario A you lose most of the benefit of components, since you expose (and force the user to understand) some of the implementation details that she should not modify.
Whereas with scenario B you get the benefit of having an encapsulated unit of code with a clear interface, while being free to modify its implementation as long as the public interface continues to work as expected.
CSS modules are about 95% of the way to making this a solved problem.
Obviously this relies on imported components implementing CSS modules, but for a greenfield project this kind of thing works remarkably well.