Effectivement, ça a pas mal changé. Je ne suis pas certain du contexte auquel tu penses en disant que ça « convertit automatiquement les variables d’un type à l’autre », mais CL ne se comporte probablement pas comme tu le crois (contrairement, par exemple, à PHP dont le code équivalent fonctionnerait sans souci) :
> (+ 1 "1")
Argument Y is not a NUMBER: "1"
[Condition of type SIMPLE-TYPE-ERROR]
La seule “conversion” qui soit effectuée automatiquement c’est sur les résultats des opérations numériques : CL considère que tout entier / fraction / flottant est avant tout un nombre, en conséquence de quoi les opérations numériques renvoient le type le plus précis possible en fonction du résultat. En pratique, la principale différence est que les divisions entières « à la C » ne sont pas considérées comme allant de soi, mais une fois qu’on est prévenu il suffit d’utiliser les bons outils (en l’occurrence, truncate) pour retrouver cette bizarrerie.
Personnellement je trouve que ce comportement encourage et facilite au contraire la programmation rigoureuse, car on a l’assurance que les calculs ne seront pas déformés par des règles d’arrondi totalement arbitraires et artificielles. 
Encore une fois, CL est prévu pour supporter les deux : dolist et progn sont des idiomes centraux du langage, et c’est typiquement de l’impératif. À l’opposé, mapcar est lui aussi totalement idiomatique, mais c’est du pur fonctionnel.
Bref, CL en lui-même n’encourage aucun style particulier, il met simplement à disposition une panoplie d’outils extrêmement complète dans laquelle chacun peut piocher en fonction de ses préférences et de ses besoins. 