I think this is a case of buyer beware, your mileage may vary, some assembly required... You get the drift.

Scalar functions, as Adam very clearly outlines, unless they're very simple & direct, generally lead to RBAR (row-by-agonizing-row) processing (all due deference to Jeff Moden) because the optimizer can't simply unpack them and add them to the execution plan in a meaningful way. So instead, Adam showed how using a table valued function, in that case, resulted in a query that the optimizer could do something with, hence a radical increase in speed (through a reduction in I/O).

It's not the case that ALL table valued functions will perform better than ALL scalar functions, but rather that there are situations where you achieve significant wins, depending on what the different functions are doing. Further, using Adam's example, you probably write a query, no function needed, that would perform even faster than the final UDF.

Personall, at my company, we've found functions just too problematic to use them much. Note the keyword, much. We do use them, but we try to very carefully identify places where we can achieve either maintenance & coding improvements at no performance cost, or performance improvements. Other than that, we try to stay away from them because they are very problematic, as Adam outlined.

Does that help at all?