¿Por qué deberíamos usar colecciones de primera clase preferiblemente?

La seguridad de tipos es una razón muy pequeña para usar colecciones de primera clase. Desde su enlace:

  

Regla 4: colecciones de primera clase   La aplicación de esta regla es simple: cualquier clase que contenga una colección no debe contener ninguna otra variable miembro. Cada colección se envuelve en su propia clase, por lo que ahora los comportamientos relacionados con la colección tienen un hogar. Es posible que los filtros se conviertan en parte de esta nueva clase. Además, su nueva clase puede manejar actividades como unir dos grupos o aplicar una regla a cada elemento del grupo.

La idea aquí es si se encuentra a sí mismo buscando, filtrando, validando, o algo más que agregar / eliminar / iterar semántica en una colección, el código le está pidiendo que lo coloque en su propia clase. Si necesita actualizar solo un valor (después de una búsqueda), probablemente se incluya en la clase de colección.

El razonamiento para esto es bastante simple, las colecciones tienden a pasar por alto. Muy pronto, 4 clases diferentes tienen su propio método SearchByID() . O obtienes valores de retorno como Map<Integer, String> con el contexto de lo que está almacenado en ese mapa eliminado. Una colección de primera clase es una solución simple que cuesta un solo archivo fuente. En la práctica, una vez que están en su lugar (también son muy fáciles de escribir las pruebas unitarias), cualquier cambio relacionado con la colección es fácil de manejar, como cuando SearchByID necesita tomar un GUID en lugar de un int.

  

... use una clase separada para completar la colección y con métodos para agregar, eliminar datos de modificación de esa colección

Esto hace mucho más que garantizar el tipo de los objetos almacenados en las colecciones, también garantiza cualquier invariante de colección.

Los árboles (rojo-negro, AVL, etc.) son sensibles a los pedidos y su comportamiento depende del rebalanceo cuando sea apropiado. El rendimiento de la tabla de hash también dependerá de un re-hashing apropiado. ¿Desea recordar verificar el factor de carga cada vez que inserta en un mapa hash?

FWIW, el texto es bastante claro al respecto (y lo editaré todo en tu pregunta, por lo que nadie más necesita descargar ese RTF):

  

Cada colección se envuelve en su propia clase, por lo que ahora los comportamientos relacionados con la colección tienen un hogar

No tiene nada que ver con los tipos (o, por lo tanto, con los genéricos), sino con la asociación del comportamiento de la colección con sus datos.

La respuesta simple es "No" si está usando un lenguaje que admita los genéricos. Debido a que no hay necesidad de verificar el tipo, ya que la característica del idioma hace un buen trabajo en esto (desde mi experiencia con los genéricos de Java).

Pero si tiene alguna situación en la que desee personalizar la estructura de datos proporcionada por el lenguaje, puede crear una clase de envoltorio alrededor de la estructura de datos original y exponer sus propias API y seguir utilizando la implementación subyacente de la estructura de datos original.