I had a couple of comments on this article. In general I thought it was good, however, there's a couple of overlooked key points here I'd like to bring up.
In issue 2, since this is a view we are working on, it's purpose is to be usable by multiple other stored procs or queries. For a view or table valued function, you DO want to return every useful column in its results. SQL Server doesn't store execution plans for a view or table valued function, they are stored within each stored proc or query that uses them and it is smart enough to choose a different plan depending on how they are used. If you don't include a useful column, then developers will do another join to get that information, and SQL Server will happily hit that same table again.
A quick example, we have an inline table valued function that gets the current status of a field agent. The TVF includes a join to a code table to get the actual description for the status, but if that column isn't used, the execution plan shows it doesn't even do the work for the join!
In issue 4, you try to avoid the scalar function issue by avoiding the data it returns, rewriting the query. Scalar functions are known for a number of bad issues, and it's probably best if it were replaced with a CROSS APPLY or TVF if possible.
It would have been interesting to see the results in the chart at the end if the SELECT from the different views only included the common used columns, instead of doing a SELECT * from the 3 different views, which is really asking for 3 different resultsets not the same resultset implemented 3 ways.