It's not redundant, an element selector has a different specificity than a class selector. Much easier to maintain when Everything Is A Class (especially when paired with BEM, for very flat selectors). It's the reason Bootstrap stopped doing this.
Who cares if it's redundant? Classes are cheap and repeated strings cost you almost nothing after Gzip.
BS has actually has an .h1 class. Eventually a design calls for an <h2> that needs to have the visual appearance of an h1 but for SEO or HTML semantics reasons needs to be an h2.
Maintaining any site of a certain size it spirals into a nightmare quite quickly. Look at how Bootstrap 4 can add a dropdown to a <div> or a <nav>. If your rule was just `nav {}` you wouldn't have that portability, `.dropdown` is clearly superior. On sites of scale modular CSS wins every time.
>It's not Bootstrap. Different paradigm.
Could have fooled me as a lot of the class names and styling are identical. If the m-* and p-* spacing utilities are identical, is it really a different paradigm? BS has (Sass) variables as well.
Should I expect an <a> with `.text-success` to overwrite `.tab-group a`? Or do I need a new class for `.tab-group .text-success`?
Look at how BS4 broke up Navs from being `.navbar > li > a` to being .navbar, .navbar-item and .navbar-link and think about why they did.
In the meantime, a borderless table could be a modifier: table-borderless (i.e. like table-striped or table-bordered).
Just a different approach than what a lot of folks are used to :)
When you mix element selectors with class, ID, and multi-class (.foo.bar) selectors the specificity of each is different, and overwriting them means writing needlessly complicated selectors that are then in turn harder to maintain.
Bootstrap 4 goes as far as eliminating most sibling/child combinators (>, +, etc) because they add specificity. Anyone that's tried to write custom classes for list elements in Bootstrap 3 (.list-inline>li) has experienced this.