Justification for bootstrap mixins like .make-row()?

Question

Layout

With the help of less, you can mix the design of the bootstrap col, row for your classes.
Now I came across a situation where one of the layout designers before me seriously used this mixing.
Isn't it more convenient, looking at the classes in the layout, to immediately understand the behavior at different widths and build on this?
What are the advantages of this approach (other than a la "semantically beautiful design")?

Answer 1

I only use .make-row() mixins and others to generate an alternate grid. For example, in parallel with the standard 12-column, you need to use a 5-column with an increased gutter.
In other cases, I write the classes “row”, “col-*” and other bootstrap classes immediately in the layout, it’s more convenient for me. Because you need to balance complexity in HTML markup and complexity in CSS code. Let's look at the extremes.
1) If you write a unique class for each block in the markup, and then add rows, cols and other properties from the framework in CSS mixins, then in HTML the complexity decreases, because we have only one class on the block, but in CSS the complexity increases dramatically: to fix a bug, the coder will have to run through mixins, analyze dependencies so that it doesn’t break somewhere else. At the same time, the size of CSS files grows: the styles for the grid are repeated in different selectors (code duplication), and the layout designer has to come up with a new unique class name for each new block. Two outwardly similar blocks have 90% of the same code and this code is repeated twice. This situation is called "css bloating" (css flood).
2) The opposite situation is called “html bloating”: when simple classes like .colorred, .fontsize14, fontweightbold, .padding20, etc. are created in styles, and 10-20 such classes are thrown into the markup for each tag, until the block will look right. In this case, the CSS is very low complexity, there are no conflicts, and the file size is small. But if the design changes even slightly, the coder will have to rewrite the classes on each tag. All the complexity from the styles has gone into the markup.
In the first case (css bloating) we have 100% separation of appearance from markup. This seems to be good, the blocks look independent, but this is achieved at a high price: there is a big risk of breaking something, making edits to mixins; repetitions in the code and as a result obligatory gzip of styles. In its pure form, it can be used when there is no access to html markup: the same widget is used on different sites and should look different, it is dangerous to change its html.
In the second case (html bloating), the look is mixed with the markup (it's only slightly better than the inline styles) and even the smallest change in design entails a bunch of dumb work of rearranging classes in html, but there is nothing to conflict in css. Perhaps, in its pure form it can be found in web applications, when the layout is generated through js templates (stupid work is automated). Catching css bugs in dynamic application layout is very difficult, so it makes sense to increase the strength of styles by transferring complexity to the markup.
The best option is to distribute the complexity approximately equally between styles and markup - “multiple classes”. Hang 3-5 classes on each block, which are responsible for the modular grid, geometry, skin of this block. The corresponding classes can be reused in other blocks. Bootstrap's classes do a good job with the modular grid and partly with the geometry, and the skins and geometry of its own components are added by the layout designer himself.
In BEM, the balance of complexity is shifted towards css bloating: blocks must be independent, they cannot be mixed, they can only be nested, which means that the number of css code repetitions has been increased.
In OOCSS, the balance is shifted towards html bloating: more small but reusable constructs are written, it is more difficult to come up with class names, because they should be abstract enough, but still show what the class does.

Answer 2

The fact that html is separated from css and in css you can immediately see what the class is intended for