Pas tout à fait une réponse, mais je vais partager mon expérience.
Le reniflage de paramètres a mis quelques années à SQL Server pour venir me mordre, lorsque je suis retourné chez Developer DBA après m'être éloigné principalement du travail de prod DBA. J'en comprenais plus sur le moteur, le fonctionnement de SQL, ce qu'il valait mieux laisser au client, etc. et j'étais un meilleur codeur SQL.
Par exemple, SQL dynamique ou CURSOR ou tout simplement un mauvais code SQL ne subira probablement jamais de reniflage de paramètres. Mais mieux vaut définir la programmation ou comment éviter le SQL dynamique ou le SQL plus élégant.
Je l'ai remarqué pour le code de recherche complexe (beaucoup de conditionnels) et les rapports complexes où les paramètres par défaut affectaient le plan. Quand je vois comment des développeurs moins expérimentés écriraient ce code, alors il ne souffrira pas de reniflage de paramètres.
Dans tous les cas, je préfère le masquage des paramètres à WITH RECOMPILE. La mise à jour des statistiques ou des index force quand même une recompilation. Mais pourquoi recompiler tout le temps ? J'ai répondu ailleurs à l'une de vos questions avec un lien qui mentionne que les paramètres sont reniflés lors de la compilation, donc je n'y crois pas non plus.
Le masquage des paramètres est un surcoût, oui, mais il permet à l'optimiseur d'évaluer la requête au cas par cas, plutôt qu'une recompilation générale. Surtout avec la recompilation au niveau des instructions de SQL Server 2005
OPTIMIZE FOR UNKNOWN dans SQL Server 2008 semble également faire exactement la même chose que le masquage. Mon collègue SQL Server MVP et moi avons passé du temps à enquêter et sommes arrivés à cette conclusion.
