solo (sorprendentemente ;-) noté la razón por la que las aplicaciones se ven tan apretadas en mis máquinas win6 + (igual para Vista y Win7, ambas con configuración de 120 ppp, jdk6 y jdk7): la fuente de control que se ve desde la propiedad del escritorio tiene la fuente incorrecta Familia y el tamaño equivocado:

public static void main(String[] args) {
    Font guiFont = (Font) Toolkit.getDefaultToolkit().getDesktopProperty("win.defaultGUI.font");
    int guiSize = guiFont.getSize();
    Font iconFont = (Font) Toolkit.getDefaultToolkit().getDesktopProperty("win.icon.font");
    System.out.println("gui default: " + guiFont + "\nicon default: " + iconFont);
}

salida:

gui default: java.awt.Font[family=Tahoma,name=Tahoma,style=plain,size=13]
icon default: java.awt.Font[family=Segoe UI,name=Segoe UI,style=plain,size=15] 

Este último se usa en aplicaciones nativas para casi todo el texto, mientras que Swing usa el anterior ...

Preguntas:

¿Podría haber alguna razón para esto, o simplemente un error?¿Quién es responsable: la búsqueda de Swing (cuando se lee en la propiedad de escritorio de los recursos del sistema relevantes) o el sistema operativo no lo informa correctamente?¿Cómo forzar el uso de este último?

Opciones para resolver el último:

Con el control total sobre el LAF, uno podría considerar establecer todas las fuentes de texto relevantes (eso es lo que hace JGoodies, factorizado en un FontPolicy / Set).Un truco sucio es establecer el valor de la propiedad de escritorio por defecto de GUI en el valor correcto: implica acceso reflexivo al kit de herramientas, que naturalmente explotará en contextos de seguridad restringida.??

Editar

En caso de que alguien esté interesado, aquí está el truco sucio:

/**
 * Replaces the default gui desktop font property with the icon font
 * if the former is smaller.
 * 
 */
public static void ensureDefaultGUIFontSize() {
    Toolkit toolkit = Toolkit.getDefaultToolkit();
    Font guiFont = (Font) toolkit.getDesktopProperty("win.defaultGUI.font");
    Font iconFont = (Font) toolkit.getDesktopProperty("win.icon.font");
    if (guiFont.getSize() < iconFont.getSize()) {
        invokeDeclaredMethod("setDesktopProperty", Toolkit.class, 
            toolkit, "win.defaultGUI.font", iconFont);
    }
}

private static void invokeDeclaredMethod(String methodName,
        Class<?> clazz, Object instance, String propertyName,
        Object propertyValue) {
    try {
        Method method = clazz.getDeclaredMethod(methodName, String.class, Object.class);
        method.setAccessible(true);
        method.invoke(instance, propertyName, propertyValue);
    } catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
        LOG.finer("forcing desktop property failed " + e.getStackTrace());
    }

}

Editar 2

Solo para aclarar: el hack es completamente efectivo solo para WindowsLAF. Nimbus ignora completamente la configuración del sistema, Metal en parte: la fuente de este último es siempre Dialog, solo el tamaño se toma de desktopProperties. Suena medio bueno, pero no lo es: la asignación es bastante rara para las fuentes principales, f.i. el tamaño de controlFont muy utilizado se establece en "win.ansiVar.font.height" (¿qué restos de fósiles es eso?) que es 13 en mi máquina ...

Editar 3

Incluso en windows ui, el hack es ... un hack con limitaciones, f.i. los mencionados en el comentario de @ Walter:

Este error es especialmente notable cuando se escala la interfaz de usuario de Windows. Para tu información, abrir un JFileChooser revierte el hack. Además, la altura de las filas de JTree / JTable no se actualizará automáticamente al nuevo tamaño de fuente y también tendrá que escalar sus iconos