Good question. (Although I hate the ALL CAPS in the code).

The QUOTED_IDENTIFIER option is a rather odd one. Frankly, I am surprised that it's not deprecated, as its only use is for backwartd compatibility.

Ancient versions of SQL Server allowed you to enclose string constans in "double quotes" instead of 'single quotes'. That bit Microsoft when the ANSI standard for SQL decided that 'single quotes' are for delimiting string constants, and "double quotes" are for delimiting identifier names. So in order to adhere to the standard, Microsoft had to change the meaning of the "double quote"; in order to not break existing code, SET QUOTED_IDENTIFIER was introduced.

All major non-Microsoft relational databases use 'single quotes' te delimit strings, "double quotes" to delimit identifiers, and [square brackets] to force syntax errors. MS-Access uses 'single quotes' to start inline comments, "double quotes" to delimit strings, and [square brackets] to delimit identifiers. And SQL Server? Well, under the recommended option (QUOTED_IDENTIFIER ON), it uses 'single quotes' for strings, "double quotes" for identifiers (as per ANSI standard), and [square brackets] for identifiers as well, but this can be changed to use both 'single' and "double" quotes for strings and [square brackets] only for identifiers.

@UMG Developer - I hope the "not hiring" comment refers to the use of "identity" and "string" as identifier names, not to the use of double quotes. Using such identifiers is indeed bad practice, using double quotes to delimit them is not - if might be an indication that the developer has a thousand years of experience in other databases, or that (s)he tries to keep code portable. To name a random example of a developer who prefers double quotes over square brackets when delimiting identifiers: me.