La verdadera razón por la que desea utilizar NVARCHAR es cuando tiene diferentes idiomas en la misma columna, debe abordar las columnas en T-SQL sin decodificar, desea poder ver los datos "de forma nativa" en SSMS o desea estandarizar en Unicode.
Si trata la base de datos como un almacenamiento tonto, es perfectamente posible almacenar cadenas anchas y codificaciones diferentes (incluso de longitud variable) en VARCHAR (por ejemplo, UTF-8). El problema surge cuando intenta codificar y decodificar, especialmente si la página de códigos es diferente para diferentes filas. También significa que SQL Server no podrá manejar los datos fácilmente con el fin de realizar consultas dentro de T-SQL en columnas codificadas (potencialmente de forma variable).
El uso de NVARCHAR evita todo esto.
Recomendaría NVARCHAR para cualquier columna que tenga datos ingresados por el usuario que no tengan restricciones.
Recomendaría VARCHAR para cualquier columna que sea una clave natural (como una matrícula de vehículo, SSN, número de serie, etiqueta de servicio, número de pedido, indicativo de aeropuerto, etc.) que normalmente está definida y restringida por un estándar, legislación o convención. También VARCHAR para ingresado por el usuario y muy restringido (como un número de teléfono) o un código (ACTIVO/CERRADO, Y/N, M/F, M/S/D/W, etc.). No hay absolutamente ninguna razón para usar NVARCHAR para eso.
Entonces, para una regla simple:
VARCHAR cuando se garantiza que estará restringidoNVARCHAR de lo contrario
