With respect, "if you are trying to devolve database access from w code for example, then defining a temp table like the db table is almost imperative IMO" is rubbish in my opinion. On the contrary, the TT's that I see passed to a .W more often than not are an aggregation of bits and pieces of different tables, collected into one place so that the .W doesn't have to know about all those messy details. As a general principle, I think you want all the detailed knowledge of tables and fields and the internals of your app centralized on the server side. The .W should, to the extent practical, strive to merely display things.
That said, I don't think there is anything absolutely wrong with LIKE, but personally, I don't like (no pun intended) the way it obscures the structure of the table in the source. But that's not a big deal. In any event, I only use it when I truly need an exact replica of the real DB table for some reason. Which is rare.
One (not very strong) reason to avoid LIKE is that it creates a dependency on a DB connection which in turn may allow unwanted DB references to creep into your code. This mostly relevant to .W's. If your .W"s run thru AppServer, it makes sense to NOT have a DB connection when you compile them, because you won't when you run them. If you use LIKE, you have to have that connection. This same concept could, I suppose, be applied to other multi-database situations.