I first became aware of the list-in-a-script-object speed-up effect when someone on the AppleScript-Users e-mail list asked about it. Then I noticed the similarity between the way the list variable is addressed in such cases — ie. as a property of the script object containing it — and when the a reference to operator is used in the way peavine mentions:
-- Script object:
script o
property lst : {}
end script
set end of o's lst to 7
-- a reference to:
set myList to {}
set listRef to a reference to myList --> myList of «script»
set end of listRef to 7 -- Effectively 'set end of «script»'s myList to 7'
The difference, of course, is that the specifier returned by a reference to is stored in a variable whereas the script object equivalent is compiled directly into the running script’s source code and is thus slightly faster still in use. An alternative, again as peavine points out, is to use the keyword my in front of the list variable. But, as with a reference to, the list variable in this case has to be a property, global, or run-handler variable of the main script. One reason to use a script object in a handler is that the variable containing the script object can be local to that handler. Besides looking neater (in my view!), it prevents the script object and the l-o-n-g list it contains from being saved back to the script file (on older systems such as my own Mojave one) when the main script finishes running. There’s nothing special about the script object label o. It’s just a habit left over from the AppleScript-Users list and can be anything else that’s legal for a variable.
The speed advantage only applies when addressing a list’s properties and items (not the list itself) and is only noticeable with really long lists or where thousands of accesses are done. With modestly-sized lists, it can be microscopically faster not to use a script object.