Are we saying that in these circumstances funtions are OK. It's only against very large tables there is a problem?

No.  A Function procedure gets optimized the same as any other procedure or query.  What matter inoarticular with functions is "How many times is it called?"

This is because the performance overhead that you incur with a function that you do not have with an in-line Join or Subselect is having to invoke the function (as a stored procedure) once for each function result.  If this is only once, then it is probably no big deal.  However, if it is say 10,000 times, then it could be a problem.

There is an additional implicit overhead assoctiated with function usage in queries because the SQL optimizer cannot do good global query optimizations across procedure boundaries.  Again, unlike in-line Joins and Subselects.

If I use Functions then the code is really easy to understand.

This is the basic quandry of SQL Server Functions:  They are much easier to read and write than complex compound Joins and Subselects.  However, they can have performance problems, depending on how they are used.

The general rule of thumb that I use is:  Functions are OK for queries that return a single result, such as OLTP and typical Create/Read/Update/Delete user apps.  However they are not OK for procedures that return or copy or manipulate many rows such as reports and typical DB maintenance tasks.