I'm not sure what best practice dictates as far as setting the "group" and "others" file permissions.
A normal approach would be 755, so group and other have read-execute permission. Pretty much everything in (e.g.) /usr/bin is set that way.
If I share my_file.sh and someone downloads it to their system, does the UID get changed to match their own? Does it depend on how the file is transferred (scp, git, http, etc.)?
Almost certainly it does get set to their UID, but there are methods that can retain the original value -- for example, if you tar the file and then open it somewhere as root, you get the original numerical UID.
There's generally no significance to that, however, unless you have some particular reason you want to deploy the file somewhere with a specific UID. If your concern is about the ability to read and modify the script, there's no way to prevent that regardless of what UID or methodology you use. Someone who transports a file to another system where they have root access can do whatever they want with it. However, they cannot replace or modify the original unless they have write permission on the original.
On the local system, a file with read-execute permission can be copied (since it is readable) and the copy will have the UID of the user who made the copy. You can set a file executable but not readable, but there is no purpose in doing so; a file must be executable and readable in order to be executed. In other words, if you want everyone to be allowed to use the script, you need minimally world read-execute permission on it.
