Pues más o menos lo que tu has puesto.

En DEBUG habría que hacer debug básicamente de todo: De los valores intermedios que van tomando las variables, de lo que devuelven los métodos, etc.

En INFO se pone las acciones con sentido en el ámbito del problema y sus resultados. El ejemplo que tu has puesto yo lo llevaría más bien a DEBUG. Yo en INFO pondría cosas como "Accedido elemento 106 (Urbanización cascos ligeros)" o "Calculado en valor de la hipoteca (DATOS: x, xx, x)"

En WARN lo que dices es lo correcto. O algún otro aviso como valores extraños encontrados en la entrada o en la base de datos.

Esa es la idea (tal y como yo lo veo)

Esta mañan estoy inspirado y me he creado algunas normas personales más.

1. Las acciones se loguean lo más inmediatamente posible después de la declaración de la función.
1.1. Puedes alejarlo de la declaración si necesitas recopilar algún dato (a parte de los parametros de entrada) para mostrarlo.
1.1.1. Si ese proceso tiene la más mínima posibilidad de fallar, loguea la entrada a la función, y posteriormente el dato obtenido.
2. Todas las líneas deben acabar con un caracter (en mi caso he elegido el punto) para evitar confusiones entre frases vagamente redactadas y valores que se han convertido a string como cadena vacía.
3. Cuando se vuelcan cadenas que pueden tener comillas, se vuelcan entre los caracteres 0171 y 0187 ("«", "»") para saber dónde comienzan, dónde acaban, y evitar confusiones de comillas más habituales.

2.
logger.debug("Se edita la subfamilia" & sSubfamilia)
Si no existe un punto al final de la frase, y sSubfamilia es una cadena vacía, entonces leerías "Se edita la subfamilia" y no sabes si hace referencia a la subfamilia de la que has hablado previamente, o a un valor que debería haber aparecido y no aparece.

3.
«Se ejecuta "SELECT * FROM t_Cosas WHERE sNombre='" & sQueCosa & "'"»