There isn't any reflection with HtmlHelpers. The last parameter isn't an object, its a dictionary, so lookup of values is via hashtable, not reflection. The HtmlHelper is nice in that its methods are safe and secure...input is encoded where necessary, security checks are peformed where needed, etc. There is a lot more to HtmlHelpers than just html rendering.
The overhead of doing reflection is something that people really like to worry about. Outside of synthetic benchmarks, however, it becomes a pretty boring topic!
In the context of a real production application (where you are doing CRUD operations against a databases or consuming a webservice for example), the overhead of using html helpers is going to be insignificant compared to the overhead of doing that kind of context switch.
Really not something to worry about especially considering the benefits html helpers provide such as automatically restoring form values from ViewData/Model, and validation support.
Bottom line: use html helpers when possible. You can always use straight html if you encounter a rare limitation that you need to work around.
I've done it both ways, and the performance seems to be about the same. Phil Haack says you can do it either way -- that the helpers are just that, helpers, and if you prefer you can write Plain Old HTML.
I'm not sure that the helpers are any safer...either way you wind up with the same HTML in the web page...but the intellisense does seem to work better in the helpers for some reason, which is nice.
Dropdowns are easier to make with the helpers, since you don't have to spin up a loop for the selection list. Hidden fields and text boxes (and links as well) look better to my eye done in plain HTML, especially if they contain several attributes, as you are able to avoid that object initialization syntax.
Plain HTML appears to mesh well with jQuery (see here for an example). And the plain HTML is just easier to read.
I imagine helper methods being useful when you want to inject a larger structure into the html. In a few months you will find websites rich with these methods, that will support all kinds of functionality. Imagine being able to inject a graph into your page with one line of code.
Your controller action (invoked by GET) results in many cases must be cached to achieve good performance. So you should not worry about your View's execution time. For me it is hard to imagine a situation where your HtmlHelper's execution time may become the performance bottleneck.