Nice... thanks for posting this, will try to remember next time I touch the build server(s).
Also, setting all projects' output folders to the same directory is a pretty bad idea. You're presumably doing parallel builds (/m). If so, and two projects depend on the same library but at different versions, which version will go into your output folder? Depends which project happens to finish building last. That's non-deterministic. Boo. What if the versions aren't even API-compatible? (e.g. Some of your test projects are still on NUnit 2?)
Using hard links gives you most of the speed up, but without the attendant issues.
/p:CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true /p:CreateHardLinksForCopyAdditionalFilesIfPossible=true /p:CreateHardLinksForCopyLocalIfPossible=true /p:CreateHardLinksForPublishFilesIfPossible=true
It will give you a considerable speed-up for very large solutions, especially if there are lots of common project dependencies, as it will make hard links instead of copying entire files. This could save you gigabytes of file copying in very large solutions. Google for "hard link" if you don't get what I mean by that.
Note that dotnet core works differently and doesn't do copy local at every stage up the dependency tree when you build, instead copying dependencies directly into your top level application project only when you run the publish target, which is obviously cheaper than either approach.