You can look at this argument from several angles including the one of a purely OO approach which says to program against an Interface not an implementation. With this thought, using IList follows the same principal as passing around and using Interfaces that you define from scratch. I also believe in the scalability and flexibility factors provided by an Interface in general. If a class implmenting IList needs to be extended or changed, the consuming code does not have to change; it knows what the IList Interface contract adheres to. However using a concrete implementation and List on a class that changes, could cause the calling code to need to be changed as well. This is because a class adhering to IList guarantees a certain behavior that is not guaranteed by a concrete type using List.
Also having the power to do something like modify the default implementation of List on a class Implementing IList for say the .Add, .Remove or any other IList method gives the developer a lot of flexibility and power, otherwise predefined by List
