The thing to understand is C# has **real arrays**, in the formal computer science sense. This means several things, among them:

1. Fixed size
2. Contiguous memory

Many other platforms have an array construct of some kind which is in fact _**NOT**_ an array, at least in the formal computer science sense, because it violates one (and usually both) of those features (though they will often paper over the latter). Rather, the platforms offer a _collection_ with the "array" name merely attached to it.

These other platforms are correct to do this, in a sense, because it turns out arrays are not what we need most of the time. A collection type is almost always far more appropriate. That is, it's extremely common to either want to be able to do things like append or remove items, look up elements by key rather than index, or for the contents to be immutable. None of these things are guaranteed by simple arrays.

Thankfully, C# includes a number of collection types as well to fill in these gaps and more, and we can use types such as `List<T>`, `Dictionary<T>`, and many other related types. It's worth noting these collection types are also closely related to computer science concepts, though the naming is not always perfect (it's possible `List<T>` should have been named `Vector<T>`, for example).

This should be enough now to understand why the practice you observed for C# is the way it is. 

___

_This should be considered a **strength** for C#, rather than a weakness._

Formally specifying the various collections gives the programmer the power and guidance to use the collection type that is actually appropriate to the situation, with less encouragement to fall back to a baseline catch-all array type. Additionally, it gives the programmer to power to use a _real_ array when appropriate, which after all exists for a reason and can have certain nice performance wins when working with truly low-level code, such as interoperating with low-level operating system or network constructs.

---

> Why then do so many developers (and API designers) seem to prefer using List<T> in returned data sets? 

I think I have explained why we don't use array, but in my opinion the choice of `List<T>` in these specific scenarios is also incorrect and has led to a lot of inefficient C# data access code over the years.

Specifically, this choice creates a tendency for code to call `.ToList()` when it would not otherwise be necessary, or to manually create a list instance to return and add each record. It forces us to fully materialize data result sets when we might otherwise be able to limit memory use to one record at a time.

In most cases, we should be using `IEnumerable<T>` instead of `List<T>`, and either skipping the `.ToList()` call or using an iterator instead of instantiating a list and adding records. Again, this would allow us to set up data processing systems that stream data one record at a time, rather than materializing entire result sets, which is what usually happens today, which could dramatically improve memory use (for I hope obvious reasons) and initial response times (because we can start stream data as we receive the _first_ record, instead of waiting for the last record to be added to a list).

This also displays the weakness of my argument that individual collection types are a strength: the types are only a strength to the degree programmers understand them and make good choices. In practice, we often still fall back to a baseline `List<T>` collection, whether or not it's really the right option. 

But as one final counter-point, this is still _no worse_ than what happens on other platforms, and still at least makes it a little easier to do the right thing now and then.