The advantage of option 2 is agility. Using composition, you can choose which parts of the list interface you expose.
Imagine that later on you decide no longer to extend from another class. By now, some of the users of your library will have used methods provided by List, so you need to implement all of the list methods yourself: add/addAll/contains/retainAll. That's a whole lot of methods to implement for a simple sales list.
Basically, this comes down to "when in doubt, leave it out" which Joshua Bloch talks about in Bumper-Sticker API Design. Every facet of an API should be as small as possible, but no smaller. You can always add things later, but you can't take them away.