Of course, that's no longer always true today. In particular, selectors like :nth-last-child() depend on information from later siblings. Defining a combinator or equivalent mechanism that allows direct selection based on later siblings is thus not out of the realm of possibility. And selecting a parent vs an earlier sibling is almost identical - the parent's start tag is immediately prior to the first sibling (or text), so the distance between "thing you're selecting" and "thing it needs to know about to evaluate the selector" is only incrementally larger. So a way of selecting a parent based on children is probably fine too.
There are a few issues that have prevented us from doing so today. For one, it's slow. Using a single one of the "backwards" sibling pseudo-classes can kick your entire page into slow-selector mode, because it breaks optimizations. The same would be true of parent selectors, probably. For two, we have to prevent nesting - siblings usually aren't too far from each other, but the root can be very far from a descendant. (Also, siblings are usually walkable by traversing an array, while parent/descendant relationships are typically pointer-based and slower to traverse.) This makes it a bit clumsy to specify.
That all said, it's on the roadmap. I plan for it show up in Selectors 5.
(Oh, and note, the "cascade" in "Cascading Style Sheets" isn't about what you're referring to. It's about a "cascade" of values for a given property colliding on a single element, and figuring out which one "wins". Thus the Cascade module <https://drafts.csswg.org/css-cascade/>. It's not the best name, but we're stuck with it. ^_^)