In what way?

No possible IndexOutOfBounds, typically pattern matching on them which forces you to handle empty cases, etc. I was fine letting the guide have this as "take our word for it" but we could expand on that if we wanted. Wouldn't do it inline though.

Hm, expanding might be valuable because "take our word for it" seems like a bad position for our "guide" 😛

I thinkthere was a better transition here because, it goes on to list the properties rather than use cases. at indicates listing specific examples. It might make sense to say something like

Lists are useful over arrays because they are immutable, 
and their data structure makes resizing them more efficient,
they are easier to work with in grain and less susceptible to bugs 
because it is a lot harder to get runtime errors. The downfalls of lists compared 
to arrays are that they are unable to modified in place, and their data structure 
makes accessing specific elements and determining the length less efficient. 
Lists are best used when the size does not matter and you are constantly 
appending or removing elements.

The downfall of that sentence structure is you lose the nice list though a better option over a list might be having the two paragraphs with their differences and then using a table to compare the features.

I guess the list would have to be reworded if these are both changed to "at" but I think it's best to say what they are "excellent at"

How?

You might want to state that Lists are more idiomatic because they are generally easier to work with and more feature rich supporting destructuring in pattern matches and the fact that they are less likely to throw runtime errors. you might also want to note that as grain is functional lists are the better choice because you they are immutable.

This rule of thumb more accurately paints the picture of determining the most efficient data structure for the use case.