El método add(<Object[]> del DefaultTableModel es especialmente lento, sobre todo en lazos cerrados como éste.

1.- DefaultTableModel usa internamente Vector, que aunque sea thread-safe, es más lento que otras colecciones
2.- add(<Object[]> convierte internamente el array a Vector
3.- Añade el elemento al Vector interno.
4.- Justifica el Vector, por si acaso DefaultTableModel se usa para crear subclases, en vez de AbstractTableModel
5.- Dispara un fireTableRowsInserted

¡Es mucho "trabajo" para cada fila que se añade! :D

Si quieres usar el DefaultTableModel en vez de crear tu propio modelo, quizás lo más recomendable sería:

1.- Construir los Vectores en tu lazo, con todas las filas
2.- Crear el DefaultTableModel con esos Vectores, fuera del lazo.

Puedes echarle un ojo a los constructores de DefaultTableModel, para ver que opciones son las que más te pueden interesar.

http://docs.oracle.com/javase/7/docs/api/javax/swing/table/DefaultTableModel.html

Sí, la idea consiste en crear la estructura de datos a partir del ResulSet, y a continuación crear el modelo de una sola vez con ella, y declarar el modelo en la tabla.

El "problema" de DefaultTableModel es que funciona internamente con un Vector de Vectores, y que si se declara con arrays bidimensionales, debe convertirlos internamente a su estructura interna.
Esa estructura interna es un Vector en el que cada posición se corresponde con una fila de la tabla, y cada elemento de la posición es un Vector con el contenido de las columnas de la fila correspondiente.

La estructura de Java que mejor se asemeja a una tabla de una base de datos es un Map.
Por eso se suele convertir el ResultSet a un Map, y crear un modelo específico que use un Map. Con un DefaultTableModel no es posible hacerlo así.

Échale un ojo a estas dos entradas de este mismo foro:

http://www.javahispano.org/java-se/post/1879373
http://www.javahispano.org/java-se/post/1868448

El CachedRowSet puede ser útil cuando se realizan siempre las mismas consultas, puesto que al almacenarlas en memoria se evita la conexión y acceso a la base de datos. Tiene el inconveniente de tener que mantener la coherencia entre el CachedRowSet y las tablas, lo que sin duda complica el código de todas las operaciones de update.
Puesto que todas (creo) las bases de datos implementan sus propias cachés de consultas, la utilidad del CachedRowSet es cuando menos discutible.

Sin embargo, creo que el problema principal (y habitual) consiste en mezclar la consulta, con la creación y declaración del modelo en la JTable.
Si por cada fila que se recibe del ResultSet se debe modificar la JTable (el añadido de cada fila al modelo dispara un listener que actualiza la vista de la JTable en el UI), nos encontramos con un serio problema de rendimiento:

1.- Las actualizaciones de la vista se deben realizar en el EDT
2.- Luego, el código del ResultSet también debe ejecutarse en el EDT
3.- Luego, el UI (no solo el de la JTable, sino todo el interface gráfico) depende de la velocidad con que se ejecute el código del ResultSet.

De ahí las quejas habituales sobre "Swing es lento" ;)

Lo que, en mi opinión es mejor:

1.- Construir el modelo en una tarea paralela al EDT, a partir del código del ResultSet
2.- Declarar el modelo en la JTable, dentro del EDT, una vez esté completado el modelo.

Otra cuestión es qué tipo de modelo utilizar. Personalmente prefiero crear uno a medida, como por ejemplo éste que uso para las JTable:

public class JPTableModel<T> implements TableModel, Serializable

private static final long serialVersionUID = 8521178060564486490L;
private transient final String[] tableHeader;
private transient final Map<Integer, List<T>> tableData;
private transient final int rows, columns, headerID;
private EventListenerList listenerList;

public JPTableModel(final String[] header, final Map<Integer, List<T>> tableData) {
this.tableHeader = Arrays.copyOf(header, header.length);
this.tableData = new HashMap<>(tableData);
this.rows = this.tableData.size();
this.columns = this.tableHeader.length;
this.headerID = JPCoreServices.getHashing().hash(this.tableHeader);
}
// aquí va el código que implementa el TableModel
}