Put differently:
Is there a good reason to choose a loosely-typed collection over a type-safe one (HashTable vs. Dictionary)? Are they still there only for compatibility?
As far as I understand, generic collections not only are type-safe, but their performance is better.
Here's a comprehensive article on the topic: An Extensive Examination of Data Structures Using C# 2.0.
Yes, as far as I understand they are only there for compatibility with existing products. You should always use the type safe version (i.e. use System.Collections.Generic over System.Collections).
The non-generic collections are so obsolete that they've been removed from the CoreCLR used in Silverlight and Live Mesh.
There might be instances where you need to store objects of unknown types, or objects of multiple different types, but if you do indeed know the type of the objects that you want to store then I cannot see a reason not to use the generic version.
Edit: As commented you can just use List<Object> - doh!
Going forward only generic collections should be used. There is also the benefit of avoiding boxing/unboxing of types in the collection. This is ineffecient, especially when you have a collection of value types that are converted to System.Object when stored on the collection, hence storing the values on the heap instead of the callstack.
With regard to using non-generic collections for storing heterogeneous collections of stuff, you can always use List<object> to accomplish the same thing. For this reason alone, I'd say there's almost no reason at all to touch the non-generic collections ever again.
The exception to this would be to maintain compatibility with systems written in other languages, or against previous versions of the .NET framework, but that's a pretty "edgy" case if you ask me.
I wouldn't jump and say that are obsolete or are going to be removed anytime soon. It's true that you should avoid using non-generic collections unless you have a reason not not use a generic version. Thousands of lines of legacy (not so legacy) code is still floating around (and will be for years) that support non-generic collections such as ArrayLists. Since these were the only collections in .NET 1.0 and 1.1, it has been widely used (and abused) throughout the year.
I still occasionally have to interact with an old O/R mapper written in .NET 1.1 that returns IList objects. I have a method that does the conversion to a generic List<>, which is not efficient, but that's the way it is.
And if you need to store different objects in the same array (weird but possible) you will need a non-generic collection. The penalty of Boxing and Unboxing is something you'll have to pay anyway.
Don't be afraid to use them if you feel that you have to.
I can tell you that XAML serialization of collections rely on them implementing either IList or IDictionary, so non-generic collections are going to be with us for some time to come.
There are also issues with COM visibility - COM interop can't be used with generics