For non-work days, I agree a table is best, and as I stated above, I have tables holding non-work dates (only). Such a table is naturally much smaller that one with all dates in it. I could certainly see creating a work days table as well too if you needed it, we just almost never need it for the type of processing that we do.
As to complexity, certainly one would use functions to hide the complexity of the date calcs and to avoid having to repeat the logic (and thus risk logic errors). I didn't feel functions were necessary just for this discussion, as I just just trying to demonstrate a more efficient alternative. Either way, if you have junior developers that can't follow a date displacement and adjustment calculation after being shown a few examples of how they work, then you have far bigger problems than whether or not to do all date calcs using a calendar table.
Indeed, we use functions to do almost all work-date-related things now, such as determining the nth working/shipping day from today, or days ago, for example.
SQL DBA,SQL Server MVP(07, 08, 09) Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."