Niet helemaal een antwoord, maar ik zal mijn ervaring delen.
Het snuiven van parameters kostte een paar jaar SQL Server om me te komen bijten, toen ik terugging naar Developer DBA nadat ik was verhuisd naar voornamelijk prod DBA-werk. Ik begreep meer over de engine, hoe SQL werkt, wat het beste aan de klant kon worden overgelaten enz. en ik was een betere SQL-coder.
Dynamische SQL of CURSOR's of gewoon slechte SQL-code zullen bijvoorbeeld waarschijnlijk nooit last hebben van het snuiven van parameters. Maar een betere programmering of het vermijden van dynamische SQL of elegantere SQL zal waarschijnlijker zijn.
Ik merkte het op voor complexe zoekcode (veel voorwaarden) en complexe rapporten waarbij standaardinstellingen van parameters het plan beïnvloedden. Als ik zie hoe minder ervaren ontwikkelaars deze code zouden schrijven, dan zal het niet lijden onder het snuiven van parameters.
In ieder geval geef ik de voorkeur aan parametermaskering boven WITH RECOMPILE. Het bijwerken van statistieken of indexen dwingt hoe dan ook een hercompilatie af. Maar waarom steeds opnieuw compileren? Ik heb ergens anders een van je vragen beantwoord met een link die vermeldt dat parameters worden gesnoven tijdens het compileren, dus ik heb er ook geen vertrouwen in.
Het maskeren van parameters is een overhead, ja, maar het stelt de optimizer in staat om de query geval per geval te evalueren, in plaats van alles opnieuw te compileren. Vooral met hercompilatie op instructieniveau van SQL Server 2005
OPTIMALISEREN VOOR ONBEKEND in SQL Server 2008 lijkt ook precies hetzelfde te doen als maskeren. Mijn SQL Server MVP-collega en ik hebben wat tijd besteed aan onderzoek en kwamen tot deze conclusie.