Hi Kel.
Deciding what’s faster than something else in any particular situation is usually a matter of understanding (or having a feel for) what the code actually does and how many times it’s going to be doing it.
Concatenation involves taking two strings (or lists, or records) and creating a third containing all the elements from the other two. If you only want to append one piece of text to another, concatenation’s the most efficient way to do it, since only three pieces of data are involved: the two original texts and the result.
If you want to build a text from several smaller pieces, concatenation’s still possibly a good option. It depends on how many pieces there are and how long they are. In a sequence of concatenations, each ‘&’ is an individual concatenation and produces an intermediate result, which is fed into the next concatenation and then discarded:
"Now is the time " & "for all good men " & "to come to the aid " & "of the party."
-- Process:
"Now is the time " & "for all good men " --> "Now is the time for all good men " (intermediate string, 33 characters)
"Now is the time for all good men " & "to come to the aid " --> "Now is the time for all good men to come to the aid " (another intermediate string, 52 characters)
"Now is the time for all good men to come to the aid " & "of the party." --> "Now is the time for all good men to come to the aid of the party." (final result)
As you can see, this simple example creates two intermediate strings totalling 85 characters. Not a lot in this case, but the more concatenations there are in the chain, the more and longer are the waste strings created.
It’s sometimes feasible to parenthesise parts of a concatenation chain to reduce the amount of work done and waste produced:
"Now is the time " & "for all good men " & ("to come to the aid " & "of the party.")
-- Process:
"Now is the time " & "for all good men " --> "Now is the time for all good men " (intermediate string, 33 characters)
"to come to the aid " & "of the party." --> "to come to the aid of the party." (another intermediate string, 32 characters)
"Now is the time for all good men " & "to come to the aid of the party." --> "Now is the time for all good men to come to the aid of the party." (final result)
Same number of steps and strings, but only 65 characters in the intermediate strings.
If you have to build a text from a very large number of smaller strings, it may indeed be worth gathering them in a list and coercing this to text at the end. The assumption (unproven, but likely) is that internally, the single coercion will build a single result from everything in the list instead of creating lots of intermediate results like the individual concatenations. The time and memory thus saved, along with the comparatively short time it takes to append pointers to lists, may make this approach worthwhile. However, the list itself will occupy memory and take a small amount of time to create. It may also still be true that a growing list is occasionally replaced (behind the scenes) with another when it exceeds the memory initially allocated to it. And the longer a list gets, the longer it takes to access its far items.
But the above’s only useful if you know exactly what the code’s going to be handling. Often you don’t. In these cases, you just have to make your best judgement. As long as a script works at all, it’s obeying the First Law of Scripting. 
And given the speed of today’s computers, the actual method used often makes no discernable difference at all.
With regard to the scripts in the topic to which you linked in post #1, I’d say it wasn’t actually necessary to create the list of text items:
You can extract the base name directly from the original and concatenate the new extension to it:
set tids to AppleScript's text item delimiters
set AppleScript's text item delimiters to "."
set new_name to text 1 through text item -2 of file_name & ".txt"
set AppleScript's text item delimiters to tids
You’re using two types of references in the same line!