OK, since nobody gave me a better solution, I did it my way and it worked, so I decided to post it back here in case anyone wants to do it too.
[My case]
We have 20+ machines working with the same version of Blender on a local server. Since I'm making changes to the original Blender add-ons (like for example added features to OBJ Importer/Exporter and so on). So, I decided that instead of having to copy the files to everyone every time I make a change, I can just make a common folder somewhere on the server and point to it from all computers using a symbolic link. That's how all machines share the same "2.93" folder which is usually located in "C:\Program files\Blender Foundation\Blender 2.93". I'm sharing this because it's important.
[Blender startup]
So, if you copy your scripts inside the scripts/startup folder located in "C:\Users<>\AppData\Roaming\Blender Foundation\Blender\2.91\scripts\startup" - they will instantly work but if you use the scripts/startup folder in the location from above, you have to have some workarounds (not sure why this is so, but some of my scripts don't work when using this one, if anyone knows why/a workaround please share). No matter where you copy the .py script though, it won't have AddonPreferences since Blender directly executes it instead of using it as an ordinary addon, which in my case is a deal braker because I'm using the AddonPreferences to turn one of my scripts On/Off and particularly using AddonPreferences because that way Blender "remembers" which was the last state even after restarting.
[Possible Solutions]
In the end I found myself writing this question and, besides that, I had 2 possible solutions in mind. The first one was, instead of using AddonPreferences, I could just write a simple .txt/.ini (it doesn't really matter) somewhere locally, which stores the last state of the Radio Button in Blender. I didn't want to create any other files and flood everyone's computers with these things, especially if sometime in the future I create more scripts that need to use AddonPreferences for other things. So, I decided to go with the second possible solution that ended up being the one I'm using.
[Solution]
Since all computers share the same scripts/startup folder (the one fakely located in C:\Program Files...), I simply created a small script that uses app handler and activates on loading a new .blend project. It installs/reinstalls and Enables my other script (the one that needs the AddonPreferences) but it's not removing it before doing so. That way it will get if there are any updates, but also will remember the state of the Radio Button. This is the code for the "script loader":
bl_info = {
"name": "<script name>",
"author": "<author>",
"version": (<version>),
"blender": (<blender version>),
"location": "<ui location>",
"description": "<script description>",
"category": "<category>"
}
import bpy
from bpy.app.handlers import persistent
@persistent
def load_scripts(dummy):
path=r"<path to file.FILE.py>"
bpy.ops.preferences.addon_install(
overwrite=True,
target='DEFAULT',
filepath=path,
filter_folder=True,
filter_python=True,
filter_glob="*.py;*.zip"
)
bpy.ops.preferences.addon_enable(module="<FILE>")
def register():
if not load_scripts in bpy.app.handlers.load_pre:
bpy.app.handlers.load_post.append(load_scripts)
def unregister():
if load_scripts in bpy.app.handlers.load_pre:
bpy.app.handlers.load_post.remove(load_scripts)
if __name__ == "__main__":
register()
A quick note is that here [path=r""] the FILE.py part is written like that to emphasize that later on when enabling the script here [bpy.ops.preferences.addon_enable(module="")], it uses the file name.
Also, in this case I only need it for this particular addon, but the path variable can also be a list of paths and later on looped to load all scripts that you need.
I hope this helps!
P.S:
After some more experimentation, it turns out that the problem comes from the fact that strings in Python are IMMUTABLE and lists are MUTABLE. So, even if I use the string method ".replace" it doesn't modify the object to which the variable points. With the case of lists however, I'm just modifying a value of the same list object instead of reassigning a new object.