These are always interesting articles, but rarely of practical value. Performance is only one concern of a website project. I've found that a greater risk by far is predictable modularization, a topic with much less "engineering" attention. Any decent-sized project is going to have to decompose their presentation declarations info manageable artifacts, which has the unwanted side-effect of spreading out existing selectors across multiple files. Add to this a tight project timeframe, several engineers that treat CSS as a second-rate language (as almost all that I've encountered do, worsening the more senior they are), and CSS' lack of selector-spacing (in the namespace sense), and you have a recipe for thermonuclear battles over selector specificity.
Selector and naming conventions can basically eliminate this problem. Module root elements have a class name that starts with a letter; module nested elements have a class name that starts with a dash. These are combined with the child selector to constrain their applicability.
What was once super-ambiguous, e.g.
body { color: black; }
.menu .item { color: orange; }
.menu .item .menu { color: black; }
.menu .item .menu .item { color: orange; }
/* and on */
body { color: black; }
.menu > .-item { color: orange; }