scala.mutable.Vector based on trie structure so it's technically much more complex than java.util.ArrayList. This complexity means that bunch of Lists sharing commong suffixes could be more lightweight than bunch of Vectors sharing common prefixes. 
That property means a lot in functional style where you often have a lot of operations which take collection and return its copy modified just a bit, like stack. Appending to large Vector could generate several new objects, prepeding to List - always one.
List is very simple to understand and reason about. It's just :: or Nil. 
Implementation of Vector is pretty much hidden, it has "dirty" optimisations and could be matched preferredly via seq extractors which refers to hidden optimized drops
Random haskell developer probably wants Stream to be default Seq instead of List. Some scalaz lover - wants more some symmetric Sequence exported to std lib.
You can not change choice of scala.Seq.apply becasuse it based on List as result of ListBuffer chosen newBuilder implementation. However you can  write your own similar Seq factory like 
object Seq extends SeqFactory[Seq] {
  implicit def canBuildFrom[A]: CanBuildFrom[Coll, A, Seq[A]] = ReusableCBF.asInstanceOf[GenericCanBuildFrom[A]]
  def newBuilder[A]: Builder[A, Seq[A]] = new VectorBuilder[A]
}
So summarizing:
- Linked list is historically most dominant collection type in functional languages
- Another sequence type could be much more useful in another domain
- You can not "switch" scala.Seq.applyto another generic type. But can import or create another object under nameSeq.
I personally find Vector(...) form more useful and concise than IndexedSeq(...). Same for List(...) instead of Seq(...) or LinearSeq(...).