When installing SQL Server you need to select a server collation. However, Setup permits you to go with a default. This may seem convenient, but it often backlashes, because the default is unsuitable for a number of reasons.
A real-world case: I was contacted by a guy who was fearing for his job, if he could not get some speed out of his database. The query he show me was a simple lookup the PK. The problem was that the application (using Java in Websphere) worked with Unicode, but the table had varchar keys. And he is located in the US, he was using SQL_Latin1_General_CP1_CI_AS, which is the default for English (United States). Had he been located elsewhere, he would probably have been using a Windows collation, and he would never had any performance issue. (Because for Windows collation, SQL Server can still seek the index when varchar meets nvarchar. Not so for an SQL collation.)
I have heard from people in other English-speaking countries like Australia and the UK,
that they have a mess of Latin1_General_CI_AS and SQL_Latin1_General_CP1_CI_AS, probably because sometimes the Windows admin change the system locale, and sometimes not. Then the person who install SQL Server does not know, and since there is a default,
he does not have to know other; he can go with the flow. The mess comes later.
And this is not going to be any better with the new _100_ collations which are the default
with some system locales.