Generally much easier for a team to understand.
If one structures CSS rules in a manner that different rules depend on each other then it makes the CSS rules hard to maintain.
Modifying one rule or even the HTML can cascade a lot of unintended styling changes. It’s about minimizing dependencies and achieving separation of concerns.
For example look at this:
.global-logs .main-logs .line-marker .descriptor--new-entries button {
background-color: transparent;
color: var(--grey-600);
}
This is quite fragile and it’s hard when you are looking “button” to find the relevant matching CSS rules - using flatter hierarchies and prefix name spaces is much easier to find the relevant class and it is less fragile to changes in HTML and CSS. i.e.
.LOGbutton{
background-color: transparent;
color: var(--grey-600);
}
The first rule style means one has to search up the markup and look at a lot of CSS rules to find what is relevant.
It gets even harder if one is injecting HTML via Javascript - very hard to find the CSS linkages with the previous form.
Another way of saying this is that LOGbutton is a lot easier to find.
Incidentally this particular example was a result of SASS expanding out nested rules which it supports. Another good reason not to use CSS preprocessors.