Your article is quite substantial. There's lots of good information in there. Thank you for writing it.
As you've brought up, I'd recommend doing an SVN copy of an existing project template to start a new project. It's a quick and easy way to get a new project file with all the right settings, and even preserves history back into the initial project setup. It also encourages people to commit their code to the repository, since it's already setup for a commit, with changes tracked, and diffs available.
For people working with newer versions of Visual Studio, or updating the SDK, your article should be quite helpful. Someone will always need to know this to keep things up to date. I also think it's a great learning exercise to go through that stuff manually at least once, and learn what it all does. At the very least, it makes the SVN copy approach easy to appreciate.
I had a few thoughts while reading through the page.
You used "SVN" in the second title, and I think there may be the occasional lurker who will come by and won't know what SVN is or what it stands for. I'd suggest "Subversion Repository". I like how you linked to the repository wiki page.
It'd be nice to add a small section on starting a new project using SVN copy, and put it just before the section on starting a new project from scratch. A single small paragraph should be enough. There's probably a post that can be linked to if more details are desired. A short mention of righ-click-drag copy-and-rename would be helpful. It's a non-obvious and very handy way of making a copy. A small picture of the shell menu would be golden.
The section on adding references has no explanation why. Most people could skip this step and never know what it was supposed to do. It controls compile order. It is useful for triggering a recompile of your project if you update the SDK projects. It's most useful for people working on the SDK. It will also cause a recompile of the project if a new SDK update is downloaded (perhaps through SVN update). Setting references is just manually declaring dependencies.
For the section on "Build Platform Toolsets", there is reference to the "error below", which is 2 paragraphs below. I think this could be restructured. Perhaps introduce the error message, saying this may occur during a project upgrade (I assume that's when it happens), state the error message, possibly box it off or somehow make it visually stand out, and then explain the reason and solution below. A path to relevant menu options would be helpful here. I'd also like to ask if you've encountered this on level projects, or only on the projects in the API folder? This isn't something I've investigated myself.
A small personal note on the configuration section, is that SDK used to be set to optimize for size over speed. Most DLL code is not run very frequently, and there is little benefit to speed optimizations, but size optimizations can affect DLL size noticeably. I was also in the habit of doing all development in release mode. I'm not actually too clear on what benefits there are to developing in debug mode, but then I've also never tried to set breakpoints in Visual Studio while developing level DLLs. Maybe this topic is worth exploring further. It would be nice to have specific points to give for why one configuration might be desirable over another.
Under the "Base Address Explained" section, I'd suggest the wording "optimizing load addresses" over "optimizing code". Also under this section, I'd suggest rewording the sentence: "By leaving a compiler default, DLLs will tend to conflict with their preferred memory address, causing relocations upon loading". I worded this badly in an earlier explanation. I think it would be more clear to emphasize this is a global problem over the development of many DLLs, where if they're all set to use the same default base address, there will be contention for that address, forcing all but one of the DLLs to be relocated.