Can I ask why you want the solution in ANSI SQL? I'm not even sure if there are any rDBMS that fully implement ANSI SQL. The only reason I point this out is that the IFNULL keyword isn't supported in a lot of major rDBMS, but there is an equivalent keyword. Here's a partial summary - http://www.w3schools.com/sql/sql_isnull.asp. Just make sure IFNULL is the right keyword for whatever system you are running against. coalesce does seem to have better support.
In all honesty, this isn't a complicated query that needs performance tuning. You're concatenating adjacent columns together within each record. Regardless of whether you use ifnull, case statements or whatever bastardization of the coalesce function you came up with, it is almost certainly going to result in the same query plan under the hood. SQL is (in most senses) a declarative language, if there is such a thing. You tell the db engine what you want and you don't have that much control over how it's done . You can certainly give hints to optimize performance, but this is not the type of query that needs it, nor is it a situation that calls for it. If you had to lookup data from other rows or tables within each record you're updating, and this was something that would be run more than once, then it's a different story.
And I will second/third/fourth everyone else who has told you that it's more important for this to be correct than look pretty or perform well. I'd love to hear why you couldn't at least restore an earlier backup to a test system and do a dry run. It'd be a lot easier to have a conversation with your boss NOW about getting a proper backup and testing strategy in place than explaining to them why the production database got borked in spite of the "formal methods" you learned in your computer science classes. I don't care how good you are - you're going to fuck something up at some point. There's no shame in doing that....as long as it's in a dev/test environment!
Also, if it takes 30 minutes to run this query against only 1,500 records, then you have more issues to worry about than denormalized data. You'd probably have a very wide table, a lot of (probably poorly thought out) indexes, and some evil triggers that call web services through a command shell or some other nefarious shit.