Is updating many columns in a MERGE statement bad for performance?
My first thought was: no, the whole row will get re-written whether you update one column or many, in both the log and data files. This should be true for simple un-indexed columns at least but there could be complications.

It may make a difference if the "extra" columns are indexed: will the engine be bright enough to know it doesn't need to make changes for what is effectively no change? Of course if the update results in the row moving to a different page because it is variable length and the update causes it to no longer fit forcing a page split, then all the indexes will need updating anyway. Another complication might be your own code in triggers if your database engine supports identifying which columns were altered (UPDATE() and COLUMNS_UPDATED() in SQL Server): if your code is dependent on that does the engine identify which columns really changed or just list those that were written to?

This will all be dependent on which database engine you are using, so you will need to specify that in your question text and/or tags to get less generic advice.