I could swear there was a question like this just a few days ago, but I can't find it...
Just adding a try/catch block is unlikely to change the performance noticeably when exceptions aren't being thrown, although it may prevent a method from being inlined. (Different CLR versions have different rules around inlining; I can't remember the details.)
The real expense is when an exception is actually thrown - and even that expense is usually overblown. If you use exceptions appropriately (i.e. only in genuinely exceptional or unexpected error situations) then they're unlikely to be a significant performance hit except in cases where your service is too hosed to be considered "working" anyway.
As for whether you should use try/catch blocks as much as possible - absolutely not! You should usually only catch an exception if you can actually handle it - which is relatively rare. In particular, just swallowing an exception is almost always the wrong thing to do.
I write far more try/finally blocks (effectively - almost always via using statements) than try/catch blocks. Try/catch is sometimes appropriate at the top level of a stack, so that a service can keep processing the next request even if one fails, but otherwise I rarely catch exceptions. Sometimes it's worth catching one exception in order to wrap it in a different exception - basically translating the exception rather than really handling it.
