That would be my understanding too.
Yes, a match would be found for the .first-nested-list>span. Even more, putting a class on span would make for a further improvement, as you said. And maybe, by doing so, there are cases where that span having a class, that alone would suffice as a selector, making for a pretty fast CSS. But..
The further point I was outlining, it's to assume we need both a tag (or a class), then a class (right to left).
If a span, in a li class first-nested-list, should be targeted differently then the other spans in the rest of the li class first-nested-list, I guess using an id rather than a tag for the third element in our compound selector would make it faster. Right?
However, this seems like an abuse of classes and ids. It looks a bit (or more) like the mess CMS are making.
I revert to my original question: making a fast CSS, using simpler selectors, using classes and ids to get rid of descendant selector, or other poor performance selectors, would this lead to a weaker CSS, by losing some of the power of cascade?
I see here a contradiction: generic selectors are what should make CSS practical. It seems that, for performance sake, we should be more specific in our selectors. And I'm not talking how much of a difference, this is subjective and arguable. I wonder if there is some difference you should account for, for bigger projects.
It would seem that for bigger projects, generic in cascade would be the logical answer. But technical reasons show otherwise. Again, this is to be discussed largely and theoretically, not attacking this or that.