Just for some color.

Let's imagine a harangued writer in SQL Server's documentation ("user education") team, one who cannot write about the new features until *after* the feature is finalized (barring a new bug causing feature changes). Back in 2000 era, some developer screams about the obvious security flaw within that era's xp_cmdshell implementation, so a dire warning about xp_cmdshell's security flaws is written (and makes it into BOL). So be it.

Years pass (5 years, to be exact), with new features piling up (all of which need lucid and voluminous documentation/user education). The original writer has moved on (5-years of absolute boredom can cause a writer to go bonkers well before the new release's punctuated moments of shear terror). So a new documentation writer adds xp_cmdshell's new proxy feature. Unfortunately, that new writer is oblivious about the 2000-era author's reason for xp_cmdshell's dire warning ("I don't know why that thing is there. Best to leave it alone."). Not many I know will question what is already in black and white. Or maybe that new writer has not read the 5-year old dire warning about xp_cmdshell in BOL (authoring tools help when one must wade thru more than 50,000 pages of accumulated documentation, by putting blinkers over one's eyes). Or maybe the new writer has other more important matters to address, such as a 5-year backlog of new features that seriously need some user education.

So goes the bureaucracy for large projects, such as one where over 500 people wrote code and less than 50 wrote documentation. Can this juggernaut be changed, by us mere users who might connect and request a reduction in the direness of a 15 year old warning (where both writers have now retired, perhaps with the UE team now outsource)? I sort of doubt it - and you can call me jaded :).