Then I would say that's the problem. Whatever implementation you leak, the problem is the lack of implementation hiding, not that the implementation looks this way or that way.
I agree, your point still holds and if anything becomes stronger, because now we've identified a concept at a higher level of abstraction to replace endpoint operations!
Hard disagree here. Encapsulation is just one aspect of implementing the abstraction. And I'm not even convinced it is the best way here. Leaving the ranges as simple structures with two public fields, but introducing an "infinity" concept is another way to go. No encapsulation but still abstract (although one may argue this is still encapsulation but at a different level - applied to range bounds instead of whole ranges).
Encapsulation of ranges doesn't actually fully solve the problem, but just moves and isolates the complexity to the private implementation of the range concept (likely a class in OOP). E.g. you want to compute if two ranges overlap - you still have to deal with the complexity of 3 cases in each argument, so total 9 cases.
And hiding the bounds is likely going to be a lot more intrusive on the existing caller code (more refactoring).
