Is there any point in undersizing VARCHAR columns?

It does impact memory usage, especially when a client program has to allocate enough memory to receive a dataset.

Bear in mind that a lot of apps (especially web apps) use UTF-8 which is a multi-byte character set. As such, you should really consider characters rather than bytes.

If I was expecting over a thousand characters, then I'd actively consider a CLOB. I'd be thinking about whether it will store plain text or some form of markup (wiki / html ?), usage with non-Euro languages. The Questions and Answers here, for example, would be CLOB, but comments can fit in a VARCHAR.

If you max out a VARCHAR, then in six months someone will want to make it bigger again, and you'd be kicking yourself for not using a CLOB.

Generally there are no performance considerations although there are side issues that might matter to you. The limit for a varchar should be thought of as a constraint like any other - it is there to enforce a business rule.

IMO the question you should be asking is "Do I want to prevent the free-text data stored in this field being longer then n bytes/chars" - that is the only determining factor when choosing between varchar(512) and varchar(4000).

Note that I am assuming you are talking about varchar the SQL type - the situation is different with pl/sql and choosing the length can be crucial for memory allocation reasons.

If a smaller value will work for 98% of the cases, but it takes a Varchar2(4000) to work for 100% of the cases, then you have little choice but to use the larger value. Creating a separate table for 2% of the values and then coordinating inserts/selects etc. would add complexity that would obliterate any memory or performance benefits from not extending the field.