While there is no questioning your function's speed or elegance, for me your first 'Note' considerably reduces the usefulness. I refer to:

 Notes:
 1.  Holidays are NOT considered.

Here in England we have eight (if I have counted right) public ('bank') holidays per year, which are weekdays that explicitly do not count as working days for things like cheque clearance. For example, 25th and 26th December (or the weekdays following them, if the 25th and/or the 26th are on a weekend) are public holidays, so one can say with certainty that December has two fewer working days than a simple 'days-weekenddays' would predict. The two public holidays associated with Easter are even more trouble.

Now, one might say that 8 days out of about 261 is nothing to worry about; but that would be against the spirit of the problem, and in any case, if that approximation were acceptable, you might as well use num_days*5/7.

Or you might choose to use a modification of the supplied algorithm, to the effect of num_workdays = num_days - 2*num_weeks - num_jan1sts - num_goodfridays - num_eastermondays...

But that is deeply cumbersome, and in any event will be wrong as soon as you change locale.

For these reasons it is my opinion that the only really practical solution is what you refer to as a "date table". I freely admit that this method does as you say involve "the creation and yearly maintenance of what usually turn out to be some rather lengthy but still finite date or sequence tables". However, if we want correctness we have to be prepared to work for it - the vagaries of our calendar and culture are such that there doesn't necessarily *have* to "be a better way"!

On the plus side, once we have accepted the need for a date table, look what we gain:

- Simple changes to the date table enable us to change locale in an instant, or we could easily have a multi-locale model

- A very little work gives us role-based date tables, for example for workers who have shift patterns such as '10 days from 14' in a non-predictable pattern

- Another little bit more work enables us to categorize dates more finely than 'workday'/'non-workday', leading no doubt to all sorts of useful reports

Once again I have nothing against your function, which does a great job of working with all the quirks of the T-SQL date functions. I'm just offering my experience that a real-world solution can't afford to not consider holidays, and for this reason a date table is the way to go.