If you mean, "Is there a penalty for declaring the field size bigger than any values that are actually stored in it?", then as long as it is declared varchar, the answer is no. Every SQL DB engine that I know of stores only the number of characters actually given in the data (plus a length value). So if you define the field as varchar(100) but only store 10 characters in it, then it will only take up 10 characters on disk (plus 2 bytes or so for the length). When in doubt, I routinely make my varchar fields ridiculously large.
If you mean, "Is there a penalty for storing long character fields," the answer is yes. Disk space today is cheap, but it's not free, so you don't want to waste it for no reason. Probably more important, it takes time to read data off the disk, so the longer your data fields are, the slower the program becomes. If the field is indexed, this can really slow down your retrievals, as every read is going to have to compare the key value against this big long field.
Bear in mind that if you give the user a big data entry field, they will use it, sooner or later.
All that said, I'd err on the side of too big rather than too small. Disk space is cheap enough that you don't want to force users to invent abbreviations on the fly because they can't fit the real data into the available field. The system I'm working on today has a product description field that is too small for many of the real names of our products, so users have to abbreviate. And of course every user abbreviates differently, so we have twenty different ways to say the same thing.