The key to classes is to only use them when something is different from its siblings. This is where BEM -- as well as HTML/CSS frameworks -- utterly screw things over.
HTML is for saying what things are, semantically, grammatically, structurally, so that the user-agent (software that reads HTML. A browser is a UA but a UA isn't always a browser) can best convey that meaning to the user. Doesn't matter if it's for a screen, a braille reader, screen reader (software reading the page aloud), search engines (which don't have eyes and could give a flying purple fish about layout/graphics/visuals), etc, etc.
It is thus that loading screen media layout/style without declaring media="screen" on the LINK or STYLE tags is ignorant incompetent trash. It's why in all but the smallest of corner cases using style="" is utter garbage.
And it's why classes that recreate the document structure are as broken and wasteful as presentational classes like class="text-center color-400-blue text-large", dragging things back to the worst of the mid-90's browser wars.
You ever heard George Carlin's standup about abortion, where "not every ejaculation deserves a name"? Well, not every blasted element deserves a class or ID on it.
Take this pen:
https://codepen.io/jason-knight/pen/poWdyvX
Comparing how BEM folks would build a broken inaccessible page header, vs. how non-BEM would do it. A fraction the markup, it's less CSS, and it's rock solid stable. I used the ID's #top and #mainMenu so they're :target / href="#top" focusable which is handy for doing "back to top" links, or in the case of the menu scriptless mobile/hamburger menus.
You call the parent elements what they are, then you let your semantics do the damned work. You don't crap classes onto everything replicating the names of the tags! That's how you end up needing to write twice or more the markup needed to do the job!
In the markup there's no reason for all those classes. In the CSS if the difference between "navbar__link" and "#mainMenu a" is a hard to follow deal breaker, well... then the folks who think that way probably shouldn't be working with web technologies in the first place.