The point is to create a monomorphic variant that avoids the problems with the polymorphic `pure` and would be consistent with the other container-types. A polymorphic `singleton` would be useful, but - in the same way that `Map.fromLIst` and `Set.fromList` are (usefully!) monomorphic despite equivalent `IsList` methods, we'd still want to have a concrete `List.singleton :: a -> [a]`.
I see a lot of "Why isn't `pure` good enough here?", so I'd like to reiterate that `pure` has issues:
- It's not immediately+syntactically obvious what's being created. List.singleton is unambiguous to read.
- Polymorphism can cause unintended changes to behavior if GHC infers a different type than you expect. Consider `length (1,2)` confusion, `fmap (+1) (Left 1)` - while these have an obviously correct instance, it can still be confusing and yield potentially incorrect results.
- Monomorphic functions can often be very useful to inform GHC about a specific type you want to fix and allow the rest of inference to work around. Typed-holes provide much better information when you have concrete types rather than constrained polymorphic types.
- Finally, monomorphic functions can be used to prevent ambiguous type errors in the presence of OverloadedLists and OverloadedStrings, especially when every other method in the chain is written on Foldable or similar constraints.