It's an interesting technique - but not one I would recommend!

The simple version has this caveat: it works "as long as they share the same primary key and the shared columns have the same names" (quote from the article). Verifying that is what takes time when preparing a data merge (be it a one-time operation or an ETL job that is to be run repeatedly). Building the actual statement is a matter of seconds, especially if you use SSMS' drag&drop techniques to copy the column list from the object explorer. The technique shown in this article doe indeed save you a couple of seconds and a few keystrokes, but at the price of having to use dynamic SQL (which means you have to run under a user account with elavated rights, and you incrue the risk of injection attacks). And worse - it invites laziness. There might be situations where the same name has been used for essentially different colum; I'll exclude those when working manuallly, but they'll be included by this procedure. Or there might be some subtle difference in how data is represented, making some conversion required.

The advanced version circuvenes some (not all!) of these problems. But I think that populating the table with column equivalences would take me more time than simply writing the INSERT, UPDATE, or MERGE statement.

Therefor, I consider this article in interesting mental exercise and good information on the information schema tables, but not a technique to be used in a production system.

On a final note: Any system with a case sensitive database collation will cause these queries to fail; the table and column names of the information schema tables are all uppercase.