Exposing the delegate method does feel like a leaky abstraction, but users can mitigate against this by returning as a List to anyone they don't want this (obviously) exposed to. In the end the goal of the interface is to communicate intent clearly and I think you're probably right: the nature of the class makes it relatively obvious that users other than the subclass implementer aren't intended to mess with the delegate directly.

Your point about the ability to swap out the delegate dynamically (e.g. to delegate across a set of lists) is a good one. With a final delegate, there's no way to do this without wrapping the delegate in something that's not a DelegatingList and yet, basically delegates. All in all, I think I'm sold on the idea of the abstract delegate getter.