The reason people are wary of using reflection unnecessarily is not performance: yes, there is some overhead to using reflection, but often, solving the problem without it requires a different approach with comparable complexity, and even if it doesn't, the overhead is seldom significant (especially for application-level development).
Using reflection, some important assumptions one can normally make about source code are broken, and tools such as "Find All References" cease to work reliably. Reflection also basically removes most of the type safety the compiler enforces in, say, C#, and most of the programming errors that a type system would normally catch and translate into compiler errors, now become runtime errors at best or very obscure bugs at worst.
So why do people use reflection then? Simply put, because despite the problems described above, it is a very valuable tool. With reflection, some of the benefits of dynamic programming can be had in a static, strictly-typed language like C#, and dynamic programming languages have shown their merits recently, especially in the realm of web programming - PHP, Javascript, and quite prominently Python, all use dynamic typing, and have proven to be good fits for web programming. But since the language is still C#, you can choose to keep most of your application in a strictly-typed OOP idiom, and write the small part where dynamic behaviour really makes a difference with reflection.
A typical example is when you need to expose methods as web service calls (using a protocol not yet built into .NET). The strictly-typed OOP approach does work, but it is overly restrictive and clumsy. But if you use reflection to map calls to methods and key/value pairs to arguments, you can write the plumbing for such a web service once and then use it on any class you like.