I personally use capitalized names for exported symbols, and think that this is the recommended practice generally (for example, Roman Maeder suggests this convention in his book, which is, while dated, still probably the best reference for package writing).

The reason for that is that one wants for the exported functions to look and feel as close to built-in functions as possible.

The mechanism to avoid clashes with built-ins is of course contexts and packages. Having similar names is only a problem when two contexts are on the $ContextPath at the same time, which in most cases can be resolved, in one way of the other, by the client of your package.

There is of course one case that stands out - the System` context, since it is always present on the $ContextPath. One way to decrease the probability of a clash with some future built-in function would be to name your exported function in some unique way, in particular add some unique prefix, like

KUBAFunction1, KUBAFunction2, ... 

That would at the same time mnemonically identify that a function belongs to a functionality related to a given package, and reduce the chances of clashes.

Having longer descriptive names also helps, since that also makes it less likely to collide with some future built-in.

My two cents.