Unfortunately this is a case where it's very hard to do a direct comparison of the relative performance since the place where any degradation would show up is deep in the WPF engine. In the early days of WPF the use of StaticResource was one of the standard performance tuning changes that was recommended and we tended to follow it pretty strictly in our organization and recommend it to others. I was really annoyed that Blend did Dynamic everything even though that helped it to render resources from other files properly at design time.
Over time my view on this has changed, due somewhat to personal experience, but also feedback from people on the Blend team at Microsoft. As you are probably aware, Blend is written completely in WPF and has a complete alternate theme (Light) that can be switched on the fly while the application is running. This is possible because they used DynamicResource for pretty much all of their styling. According to them, this didn't really cause them any real perf issues. Given that Blend is probably the most widely used WPF application in existence, I tend to give significant weight to their views.
The other thing to consider is DynamicResource's actual usefulness. The ability to change styling on the fly is one part of it, but also the flexibility it gives you in building your Resource hierarchy can make it a lot easier to manage shared styles. I'm sure you've run into a situation where a StaticResource reference blew up at runtime because the resource it pointed to was to be loaded in a different branch of the hierarchy.
Obviously StaticResource is very useful for pointing to a specific key that you know is going to be available at the right time. When hand-writing XAML I still tend to use it all the time. But given the productivity you gain out of having a designer generate your XAML in Blend, any small performance gain you might get is probably not worth the overhead of hand-maintaining everything as Static.
