Inte riktigt ett svar, men jag delar med mig av min erfarenhet.
Parametersniffning tog några år av SQL Server att komma och bita mig, när jag gick tillbaka till Developer DBA efter att ha flyttat till mestadels prod DBA-arbete. Jag förstod mer om motorn, hur SQL fungerar, vad som var bäst att lämna till klienten etc och jag var en bättre SQL-kodare.
Till exempel, dynamisk SQL eller CURSOR eller helt enkelt dålig SQL-kod kommer förmodligen aldrig att drabbas av parametersniffning. Men bättre programmering eller hur man undviker dynamisk SQL eller mer elegant SQL kommer sannolikt att göra det.
Jag märkte det för komplex sökkod (många villkor) och komplexa rapporter där parameterstandarder påverkade planen. När jag ser hur mindre erfarna utvecklare skulle skriva den här koden kommer den inte att drabbas av parametersniffning.
I vilket fall som helst föredrar jag parametermaskering framför WITH RECOMPILE. Uppdatering av statistik eller index tvingar fram en omkompilering ändå. Men varför kompilera om hela tiden? Jag har svarat någon annanstans på en av dina frågor med en länk som nämner att parametrar sniffas under sammanställningen, så jag tror inte heller på det.
Parametermaskering är en overhead, ja, men den gör det möjligt för optimeraren att utvärdera frågan från fall till fall, snarare än total omkompilering. Speciellt med omkompilering på satsnivå av SQL Server 2005
OPTIMERA FÖR OKÄNT i SQL Server 2008 verkar också göra exakt samma sak som maskering. Min SQL Server MVP-kollega och jag tillbringade lite tid med att undersöka och kom fram till denna slutsats.