Take a look at the accordian component (the very first one in their system) and check it out in the dom inspector - it has a shadowroot that has precisely one child: a <slot> element. In this situation a shadowroot does nothing to help. All it means is instead of just creating children for the element, you have to create them and add "slot='item'" to all of them. Shadowroots are great when you need encapsulation of styles or static non-content UI, but with this outer element neither of those are true. There isn't any additional UI, nor styles. This is something I see a lot in lazy libraries - they automatically create a separate dom tree even if it isn't needed whatsoever.
This tells me either the library requires this every time (going against the "lightweight / low memory" motto), or the developer for this one didn't have enough understanding of when to use shadowroots.
That's not to say this is all bad though - their design system tokens are really nice and provide a lot of flexibility. I'll probably emulate a lot of them for the next webcomponent based design system I'm working on. Their algorithmic color palettes are interesting, but so far I've never found a solid algorithmic color generator - color is simply too tied to trends and too subjective to be algorithmically made. Curious to see it work in practice, and a shame they don't provide examples of it.