Understanding how AppleScript deals with file and folder references is a headache, and it's very well known to be convoluted and fussy about file specifiers and path strings.
Simple definitions:
Posix path: A path made up of forward slashes that separate folders in a directory tree, e.g. /Users/CK/Downloads/Some_File.txt.
The root (top-level) directory is represented by a single forward
slash, /. Every posix path is descended from this root directory,
so, generally speaking, posix paths must start with a forward slash.
Folder paths ideally end with a terminating forward slash; file paths
do not; but this is not strict.
HFS path: A path made up of colons that separate folders in a directory tree, e.g. Macintosh HD:Users:CK:Downloads:Some_File.txt.
The root directory is represented by Macintosh HD:, which always
begins an HFS path (unless your system hard drive is called something
else). Folder paths ideally end with a terminating colon; file paths
do not; this is semi-strict.
That's literally all you need to know about posix paths and HFS paths to do some AppleScripting. The tough part is getting to grips with AppleScript's file class types. There are three:
alias: These are your friends, and are the most versatile when used with either Finder or System Events, and when referring to
either files or folders. They are an AppleScript object that
contain a file reference that points to an existing file. Trying
to assign an alias class type to a file reference of a file that
does not exist will throw an error.
file: These are a file reference object that may point to a file that doesn't exist (yet). It qualifies an HFS path string,
identifying it as not just a piece of text, but a path to a file. The
key difference between file and alias is that file is a static
reference, meaning that if it points to a file with a given name, and
that file's name changes, the file object will now reference a file
that does not exist. An alias, on the other hand, dynamically
shifts its reference even after a file is renamed or moved.
POSIX file: If you like using posix paths (and you should), the POSIX file object is your best friend. It takes a posix path
string and qualifies it as a path to a file in much the same way
file does for HFS path strings. Likewise, it is a static reference
and can point to files or folders that don't exist.
My recommendation
My feeling is that HFS paths are an unnecessary complication to what could have been an easy inter-formulation between command line users and AppleScripting. They do confuse people, and since the notation is so widely observed through the results returned by an AppleScript, they appear mandatory in their use.
They are not. I, personally, never use HFS paths. (Almost never).
One isn't intrinsically better than the other, and it is really just a personal preference. So my advice is to pick one style that you're most comfortable with, and learn how to manipulate that type of path in the AppleScript setting.
As I use posix paths, I concern myself with POSIX file objects, and alias objects. That's what I'll focus on now for the rest of this answer.
Your script
Your script threw its first error because you attempted to escape the spaces within the file path string, possibly a habit from typing in a terminal. You don't need to escape any characters in a file string, except for the backslash \, as file path strings will always be enclosed within double quotes.
Still addressing the first line of your script, you have quite correctly retrieved the path to the library folder (which returns an alias); turned it into a posix path string; then appended the "Application Support/myApp" path text. However, it may be helpful to know that you can actually get the path to the application support folder, so your first line can become:
set localLocation to POSIX path of (path to application support from user domain) & "myApp"
The result is a posix path string, but not a file object (but that's fine at the moment).
Your next line then explicitly declares a posix path string:
set usbLocation to "/Volumes/myUsb/myApp"
which is absolutely fine.
The bit that comes next is the tricky stuff: working with Finder:
tell application "Finder" to move entire contents of ¬
folder localLocation to folder usbLocation
That said, you had it almost perfect. Because you're using posix paths, you either need to turn them into alias objects, or explain to finder that it's dealing with a posix path, which is what the POSIX file object does.
To create a POSIX file object, you can either prepend the POSIX file specifier to the posix path string like this:
set usbLocation to POSIX file "/Volumes/myUsb/myApp"
or do a more conventional coercion into a type class like this:
set usbLocation to "/Volumes/myUsb/myApp" as POSIX file
In either case, AppleScript turns this into a file object and converts it to an HFS path. If you run that line just above by itself, AppleScript returns this:
file "Macintosh HD:Volumes:myUsb:myApp"
So, already, we can see there's an equivalence between file objects and HFS paths versus POSIX file objects and posix paths.
You can choose to edit lines 1 and 2 of your script to construct these POSIX file objects straight away; or you can do it at the point where you are interacting with Finder:
tell application "Finder" to move entire contents of ¬
folder (localLocation as POSIX file) to folder (usbLocation as POSIX file)
If doing it here, you have to coerce using as, possibly because prepending it as an object specifier interferes with folder in the role of an object specifier.
That should successfully move all the files into their new location. The other way you could do it is by moving the folder instead of its contents, which is probably quicker if there are many files and sub-directories. Just change the destination path accordingly:
set localLocation to POSIX path of (path to application support folder from user domain) & "myApp" as POSIX file
set usbLocation to POSIX file "/Volumes/myUsb/"
tell application "Finder" to move folder localLocation to folder usbLocation with replacing
(the with replacing is because the folder myApp in the destination will be getting replaced by the folder myApp coming from your hard drive.)
Finally, for completeness, I'll briefly talk about alias objects:
Alias objects
Constructing alias objects from posix paths is fairly simple, and requires two steps. Firstly, you construct the POSIX file object as I showed you above. Then, you coerce this object into an alias. It can be done on one line:
set usbLocation to POSIX file "/Volumes/myUsb/myApp" as alias
or
set usbLocation to "/Volumes/myUsb/myApp" as POSIX file as alias
Remember, however, that alias objects point to files and folders that already exist. Therefore, there will be some instances where you can declare your POSIX file object immediately from a posix path string that points to a non-existent file that, for example, you will be creating. But you can only coerce it into an alias after the file has been created.
One reason you might want to use alias objects is because they are dynamic, as I mentioned before (or, they should be). So if you set localLocation as an alias object at the start, then moved the folder to its destination as in my very last Finder example, the alias object should now automatically point to /Volumes/myUsb/myApp/ (although it doesn't always work successfully, as one of the many bugs AppleScript has).
The other, more important, reason to use alias objects is that they translate directly between the different applications AppleScript interacts with: not all utilise POSIX file objects, and some may not utilise HFS paths; but they virtually all know what an alias object is.
This is key when switching between Finder and System Events for file handling. Generally speaking, file and folder handling is best done with System Events rather than Finder. But, there are a couple of things you can only do in Finder: set a file tag (label index); get the selected files (selection); and know which target folder has focus at the present time (insertion location).
Retrieving the selection in Finder returns Finder-specific classes, namely document files. One cannot utilise these objects with System Events. However, the selection as alias list is something that can be manipulated by System Events:
tell application "Finder" to set S to selection as alias list
tell application "System Events" to get properties of item 1 of S
Finally, the third reason to utilise alias objects is because, for some reason, retrieving files as alias objects is noticeably faster than retrieving them as any other class object. Testing this on the contents of my downloads folder (which is small enough to not keep me waiting, but large enough to get Finder working), the results were:
tell application "Finder" to get entire contents of ¬
(path to downloads folder) as alias list
-- 1.45s
tell application "Finder" to get entire contents of ¬
(path to downloads folder)
-- 2.29s
They are identical statements, with the exception of the coercion to an alias list (a list of alias file objects) in the first. The speed benefit will be more noticeable on larger folders.
Utilising alias objects with Finder is a little easier/simpler than with file or POSIX file objects, because alias objects don't make a distinction between files and folders in the way that the other two do. In your script, it's necessary with Finder to use the folder specifier with the POSIX file objects; with an alias object, you don't need to:
set localLocation to POSIX path of (path to application support folder from user domain) & "myApp" as POSIX file as alias
set usbLocation to POSIX file "/Volumes/myUsb/" as alias
tell application "Finder" to move localLocation to usbLocation with replacing
