What is the benefit of using CSS preprocessors to include the name of its parent in a nested style name?

Question

css

Will explain. For example, we have footer. And we need to describe his styles. There are conditionally two options that I have encountered when using Sass / Less preprocessors by authors:
1. Without including parent names in child names:

.footer_bottom
  display: flex

  .autor
    text-align: left

  .policy
    text-align: right

  .company
    text-align: right

Which in the end gives us this code:

.footer_bottom {
  display: flex;
}
.footer_bottom .autor {
  text-align: left;
}
.footer_bottom .policy {
  text-align: right;
}
.footer_bottom .company {
  text-align: right;
}

2. With the inclusion of the names of parents in the names of descendants:

.footer_bottom
  display: flex

  &--autor
    text-align: left

  &--policy
    text-align: right

  &--company
    text-align: right

And this eventually gives us this code:

.footer_bottom {
  display: flex;
}
.footer_bottom--autor {
  text-align: left;
}
.footer_bottom--policy {
  text-align: right;
}
.footer_bottom--company {
  text-align: right;
}

It is clear that these are rather synthetic examples, but the essence, I think, is clear. As a result, in a more or less complex project, monsters like these come out:

At the same time, the code structure for such a page component looks something like this:

Where the root file imports all these subcomponents into itself:

Note that the import occurs at the level of the parent element, into it and nowhere else , that is, in my opinion, nothing obliges us to use such code in subcomponents (see the red arrow), which would include the parent name in the child names:

So the question is: is there any practical use for using parent names in child names when writing CSS? Except that it might be easier for someone to read the finished css after that. In my opinion, this only makes it more difficult to write html for such CSS and then read the finished code in the browser.

Answer 1

Read about BEM. Moreover, it is desirable not just a brief explanation of the methodology, but with historical calculations, where and why it came from. It is also very useful to listen to Vitaly Kharisov's old lectures on this topic.
PS For my taste, the above example with a bunch of imports is overcomplicated. It makes no sense to pull out each element of the block into a separate file. Why a separate file with a dozen lines of code? And if there are a lot of them, then most likely the block should be divided into subblocks.