TFS build process templates vs MSBuild

The introduction of build process templates (implemented with WWF / XAML) with Team Foundation Server 2010 did not mean the end of MSBuild scripts. After all every .csproj or .vbproj project file Visual Studio generates during creation of new projects is a MSBuild script.
WWF build process templates provide a higher level orchestration layer on top of the core build engine MSBuild and has some more sophisticated possibilities that are coming with WWF, e.g. distribute a process across multiple machines and to tie the process into other workflow-based processes.
But still, a lot of steps you want to have within your project specific build (e.g. Stylecop analysis, NDepend static code analysis, script and style bundling and minification) can be realized in both ways. So the question arises which way to go: WWF or MSBuild.

I found an guideline from Jim Lamb (who is a TFS programm manager at Microsoft) how to handle this:
MSBuild is the tool of choice in the following scenarios:

1) the task requires knowledge of specific build inputs or outputs
2) the task is something you need to happen when you build in Visual Studio (so for example you have to decide if you want to have a StyleCop check for every local build or only after check-in)

Jim's recommondation is to use WWF in all other cases.

In my opinion the WWF approach has also it's downsides:
1. While it is quite simple to let an MSBuild script run on a developers machine (e.g. for debugging a build problem) this isn't so simple with the WWF solution (you had to install TFS build service locally).
2. The WWF approach can not be reused when your organization switches from TFS to another ALM platform (e.g. Subversion and TeamCity).
3. You have to know not only how MSBuild works but also have to have a clue at least of the basics of the WWF stuff.

When leveraging MSBuild, keep in mind that from a maintenance and reuse perspective it is better to create additional MSBuild files (can be referenced by "import" statements) rather than writing the additional task directly into the project files (they are already containing enough stuff).